From rick_knight at rlknight.com Mon Aug 4 13:25:10 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Mon, 04 Aug 2008 12:25:10 -0700 Subject: [Rxtx] Sun's Comm API? Message-ID: <48975796.4010600@rlknight.com> I have an application that requires the javax compatible version of RXTX and Sun's comm api. I've been able to download and extract the version of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api anywhere. Can someone tell me where I can find it? Or maybe send me a copy? Also, when I try to build RXTX, configure and make complete successfully but make install failes with this error libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 I've never come accross this error before. How can I get past it? Thanks, Rick From bboyes at systronix.com Mon Aug 4 19:10:01 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:10:01 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48975796.4010600@rlknight.com> References: <48975796.4010600@rlknight.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/cb9c6167/attachment-0002.html From bboyes at systronix.com Mon Aug 4 19:12:37 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:12:37 -0600 Subject: [Rxtx] Towards an RXTX release - CSR BT/USB chipset In-Reply-To: <488FB7E7.8000802@gmail.com> References: <460801A4097E3D4CA04CC64EE648584806C56CF0@ism-mail03.corp.ad.wrs.com> <13557-75390@sneakemail.com> <20980-23424@sneakemail.com> <488FB7E7.8000802@gmail.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/52236088/attachment-0002.html From tjarvi at qbang.org Mon Aug 4 19:42:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 19:42:21 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: On Mon, 4 Aug 2008, Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: > I have an application that requires the javax compatible > version of RXTX > and Sun's comm api. I've been able to download and extract > the version > of RXTX that I need (2.0-7pre2) but I can't find Sun's camm > api > anywhere. Can someone tell me where I can find it? Or maybe > send me a > > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm port > support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have just > a ZIP with only the .class JAR file - no source or docs), has a readme > with these comments: > > This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release.? The 2.0.3 release itself is > no longer distributed.? comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project.? The RxTx project (http://www.rxtx.org ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org) was opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support.? Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins.? Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > ? > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > I hope that is helpful! > It would be nice to work with Sun to resolve those longstanding issues. But it may not be practical unless the process goes as fast and painless as the grandfathering of commapi did. Another option may be the old kaffe extensions that moved to gnu classpathx. These don't have the native libraries but should provide the 2.0 interface and the javax.comm.properties mechansim for SPI. http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Mon Aug 4 20:23:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Mon, 04 Aug 2008 20:23:57 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4897B9BD.5070809@ergotech.com> Has there been any work/would it be possible, to layer a javacomm look-alike on top of the GNU code? The goal is not to move the javax code forward, but to emulate the "legacy" javax packages for people who still need this. Jim Trent Jarvi wrote: > On Mon, 4 Aug 2008, Bruce Boyes wrote: > >> At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible >> version of RXTX >> and Sun's comm api. I've been able to download and extract >> the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm >> api >> anywhere. Can someone tell me where I can find it? Or maybe >> send me a >> >> >> javaxcomm has had a sort of on-again off-again history. The windoze >> version has been languishing for years (literally) but there are newer >> versions for other OS's. >> >> We try to keep links on one of our help pages current: >> http://www.practicalembeddedjava.com/tools/javatools_list.html >> which gets you to here: >> http://java.sun.com/products/javacomm/ >> where it says in fact they no longer even support Windows and Mac: >> "Implementations of the API are currently available for Solaris SPARC, >> Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so >> someone could support it. But I guess that's part of the reason RXTX >> exists! >> >> So one of Sun's own products, SunSPOT, has to use RXTX to get comm port >> support. >> >> The version we use is 2.0 from 11/15/1998. I have posted it on our >> website, which is within the terms of the license agreement contained >> therein (as I understand it). >> >> The last version of javaxcomm for Windows, 2.0.3, (for which I have just >> a ZIP with only the .class JAR file - no source or docs), has a readme >> with these comments: >> >> This distribution contains the comm.jar file original part >> of the COMMAPI 2.0.3 release. The 2.0.3 release itself is >> no longer distributed. comm.jar, which contains the comm >> API java class files (eg. Sun's binary implementation of the >> interface classes), is being made available, unsupported, >> with no obligation to fix bugs, at the request of the RXTX >> project. The RxTx project (http://www.rxtx.org ), uses the >> comm.jar class files, but provides their own native library >> components to provide support for other platforms. >> >> The 2.0.3 comm.jar is being provided in this way because >> as of COMMAPI 3.x, the java binary implementation forked and >> became incompatible with the RxTx project's native code. >> Due to the lack of a clear business case, and to resource >> constraints, no additional resources are being >> provided to provide an alternative engineering solution >> at the time of writing. >> >> RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: >> >> Ultimately the COMMAPI would be better served if a Java >> Community Process JSR (http://www.jcp.org) was opened and >> the COMMAPI was rearchitected to provide a more pluggable >> framework to improve cross-platform support. Such an >> architecture would embody a better defined and better >> documented SPI interface, including a way for comm. ports >> to be revealed to the client application through the API >> via platform-aware plugins. Similarly, native code used >> to access comm port in general could be handled more >> flexibly using a plugin model, whereby on any platform, >> multiple native modules could be in use simultaneously. >> >> Since there are now various ways serial ports can be implemented >> and accessed, modular comm. port JNI native libraries would be >> of benefit insofar as removing the burden of over-generalization >> from any single native component, or inversely, by relieving the >> implicit constraint that comm. drivers be accessed only via a >> monolithic mechanism, such as the UNIX vnode interface. >> >> paul.klissner at sun.com >> 6/10/06 >> >> I hope that is helpful! >> > > It would be nice to work with Sun to resolve those longstanding issues. > But it may not be practical unless the process goes as fast and painless > as the grandfathering of commapi did. > > Another option may be the old kaffe extensions that moved to gnu > classpathx. These don't have the native libraries but should provide > the 2.0 interface and the javax.comm.properties mechansim for SPI. > > http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Mon Aug 4 21:09:15 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 21:09:15 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? Message-ID: Hi Jim, I will not step into the javax.comm namespace without Sun's explicite permission. I fully understand the pain point you are trying to address. In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm Linux) - which remains an integral part of rxtx. At the time it was a win for Sun and rxtx. The Sun commapi license is/was fairly clear that rxtx should not step into that namespace. It made sense as Sun was active in that space and rxtx may go into another namespace - it was an experiment in working with Sun. This may sound silly looking at something that happened almost 10 years ago. In a community of respect which Sun helped create, there is no question about what to do. I hope eventually Sun will step up and do a right thing too. I agree that this is hurting the API more than helping it. There are also questions about how to replace the API in the long term which includes HID support which isn't going well so far. Others that can't even look at Sun's javax.comm today and can look at Kaffe's contribution to classpathx can easily work around such restrictions. On Mon, 4 Aug 2008, Jim Redman wrote: > Has there been any work/would it be possible, to layer a javacomm > look-alike on top of the GNU code? > > The goal is not to move the javax code forward, but to emulate the > "legacy" javax packages for people who still need this. > > Jim > > Trent Jarvi wrote: >> >> It would be nice to work with Sun to resolve those longstanding issues. >> But it may not be practical unless the process goes as fast and painless >> as the grandfathering of commapi did. >> >> Another option may be the old kaffe extensions that moved to gnu >> classpathx. These don't have the native libraries but should provide >> the 2.0 interface and the javax.comm.properties mechansim for SPI. >> >> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From florianmanschwetus at gmx.de Tue Aug 5 05:04:46 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 13:04:46 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: References: <48971C1F.9020806@gmx.de> Message-ID: <489833CE.1040801@gmx.de> Just look at sendCommand in this method I have to place a Thread.sleep(20) after each byte send to get working. Even the event based receive doesn't work fine but this could be may stupidness. The specifikation document (it is on the last pages of the manual) for the beamer could be found on: http://www.optoma.co.uk/support.aspx Florian Manschwetus Trent Jarvi schrieb: > > Hi Florian > > Sorry for the top post in advance. I worry you may not see my answer > under all your code :) > > I have not received this email before. This is 500k of code which I > don't have time to read. I can spend about 5 min on each hobby email > and still get to work in the morning. I have a couple suggestions for > how to get an answer. > > First, cut out your comments and extra code so you can demonstrate the > question (I might even glance and see what is wrong then). Don't go for > a working final product. Isolate the problem using a simple program and > then ask with that as an example. If I did what you just did, I'd have > to post 3/4 of a million lines of code :) > > Second, join the rxtx mail-list and ask there. This will give you 100x > more eyes. I'll also read and try to follow. > > -- > taj > > > > On Mon, 4 Aug 2008, Florian Manschwetus wrote: > >> It could be that my university account is blocked by filters so >> resending from here. >> >> >> Topic is to control Optoma HD80 beamer using rs232 serial chat. >> This code is able to detect power state and switch the beamer on / off. >> connected is the beamer using a digitus usb 2.0 serial adapter with an >> FT232 USB-Serial adapter the systems architecture is amd64. >> >> Please take a look in the sendCommand routine i have to place theire >> those Thread.sleep to get it working. >> Now the question is this correct or is there a better way to get this >> working correctly? >> >> In the javadoc coming with the install i found this: >> setBaudBase >> >> public boolean setBaudBase(int BaudBase) >> throws UnsupportedCommOperationException, >> java.io.IOException >> >> Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 >> before using. >> >> could this explain the error? >> I attached my java source and the protocol description for the beamer >> (available on vendor website). >> >> thx, >> Florian Manschwetus >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: TestRS232.java Type: text/x-java Size: 9143 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0004.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0005.bin From michael.erskine at ketech.com Tue Aug 5 05:53:49 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Tue, 5 Aug 2008 12:53:49 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489833CE.1040801@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> > Just look at sendCommand in this method I have to place a > Thread.sleep(20) after each byte send to get working. Even the event > based receive doesn't work fine but this could be may stupidness. Hi Florian, Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. Regards, Michael Erskine. From florianmanschwetus at gmx.de Tue Aug 5 07:28:15 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:28:15 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> Message-ID: <4898556F.8000208@gmx.de> Michael Erskine schrieb: >> Just look at sendCommand in this method I have to place a >> Thread.sleep(20) after each byte send to get working. Even the event >> based receive doesn't work fine but this could be may stupidness. > > Hi Florian, > > Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. > > Regards, > Michael Erskine. > Ok, sounds fine for the receiving problem. But why i have to wait after each byte when sending a command squence? (the for loop in send command) Florian > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/284f350c/attachment.bin From florianmanschwetus at gmx.de Tue Aug 5 07:44:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:44:14 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <4898592E.2020908@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >>> Just look at sendCommand in this method I have to place a >>> Thread.sleep(20) after each byte send to get working. Even the event >>> based receive doesn't work fine but this could be may stupidness. >> >> Hi Florian, >> >> Yes, naturally you'll have to wait for a response from the other end. >> Why not wait for notification from the event thread perhaps using a >> BlockingDeque rather than your LinkedList. Generally I >> try to decouple all input and output streams: in your case your >> application is operating synchronously like the "expect" program >> (http://expect.nist.gov/) so waits (or timeouts) will need to be >> factored in. >> >> Regards, >> Michael Erskine. >> > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) > > Florian Furthermore there is this basic baud with this confusing javadoc entry: public boolean setBaudBase(int BaudBase) throws UnsupportedCommOperationException, java.io.IOException Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 before using. maybe this could explain something Florian >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/006c7425/attachment.bin From jredman at ergotech.com Tue Aug 5 09:13:36 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 05 Aug 2008 09:13:36 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: Message-ID: <48986E20.3060104@ergotech.com> Trent, So two issues: 1) Technically I'm still not sure how easy/practical a layer would be. The problems are always classes like listeners, and wrapping returns of gnu.io classes. I really see it as a "delegate" type of concept. Any thoughts or ideas of the practicality of this approach? The idea is not to modify RXTX. 2) Javax. The javax namespace does seem to be in widespread use outside of Sun (the same is true for the java namespace). The classpath extensions, or some other location, should be interested in a JavaComm implementation even if it does have dependencies on RXTX. Would you have any philosophical objection to an approach like that? Of course, I suspect it might be better if someone with that authority at Sun would admit that the javax namespace is already in the wild and that there is no problem with it being used within RXTX. Jim Trent Jarvi wrote: > Hi Jim, > > I will not step into the javax.comm namespace without Sun's explicite > permission. I fully understand the pain point you are trying to address. > > In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm > Linux) - which remains an integral part of rxtx. At the time it was a win for > Sun and rxtx. > > The Sun commapi license is/was fairly clear that rxtx should not step into that > namespace. It made sense as Sun was active in that space and rxtx may go into > another namespace - it was an experiment in working with Sun. > > This may sound silly looking at something that happened almost 10 years ago. > In a community of respect which Sun helped create, there is no question about > what to do. I hope eventually Sun will step up and do a right thing too. > > I agree that this is hurting the API more than helping it. There are also > questions about how to replace the API in the long term which includes HID > support which isn't going well so far. > > Others that can't even look at Sun's javax.comm today and can look at Kaffe's > contribution to classpathx can easily work around such restrictions. > > On Mon, 4 Aug 2008, Jim Redman wrote: > >> Has there been any work/would it be possible, to layer a javacomm >> look-alike on top of the GNU code? >> >> The goal is not to move the javax code forward, but to emulate the >> "legacy" javax packages for people who still need this. >> >> Jim >> >> Trent Jarvi wrote: >>> It would be nice to work with Sun to resolve those longstanding issues. >>> But it may not be practical unless the process goes as fast and painless >>> as the grandfathering of commapi did. >>> >>> Another option may be the old kaffe extensions that moved to gnu >>> classpathx. These don't have the native libraries but should provide >>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>> >>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From sandeep at genevasoftech.com Tue Aug 5 11:18:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Tue, 05 Aug 2008 22:48:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <48988B6C.5080409@genevasoftech.com> Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. *-- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/ad20f1cb/attachment.html From Martin.Oberhuber at windriver.com Tue Aug 5 13:30:17 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Tue, 5 Aug 2008 21:30:17 +0200 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Sandeep, shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on Sol7 but I've successfully run it on Sol9 and Sol10. Or is your request really about a native 64bit variant? I'm afraid that then you're out of luck since I think that quite a bit of RXTX is not yet ready for 64 bit. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Sandeep Kumar K Sent: Tuesday, August 05, 2008 7:19 PM To: rxtx at qbang.org Subject: [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so for Solaris 9 Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. -- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/81b7f988/attachment-0001.html From tjarvi at qbang.org Tue Aug 5 22:38:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 22:38:34 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 5 Aug 2008, Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built > on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid that > then > you're out of luck since I think that quite a bit of RXTX is not yet > ready > for 64 bit. > While rxtx-2.1-7 probably has problems, The CVS code should be OK for 64 bit Solaris. If it isn't, let me know and I'll find which patch is missing. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Aug 5 23:13:00 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 23:13:00 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48986E20.3060104@ergotech.com> References: <48986E20.3060104@ergotech.com> Message-ID: On Tue, 5 Aug 2008, Jim Redman wrote: > Trent, > > So two issues: > > 1) Technically I'm still not sure how easy/practical a layer would be. The > problems are always classes like listeners, and wrapping returns of gnu.io > classes. I really see it as a "delegate" type of concept. Any thoughts or > ideas of the practicality of this approach? The idea is not to modify RXTX. I have not put too much thought into this. I assume you want what rxtx 2.0 provided to tie into javax.comm implementations. More classes could be added to rxtx 2.1-7 for SPI support. Maintaining rxtx-2.0 could also be handed to someone if they like. > > 2) Javax. The javax namespace does seem to be in widespread use outside of > Sun (the same is true for the java namespace). The classpath extensions, or > some other location, should be interested in a JavaComm implementation even > if it does have dependencies on RXTX. Would you have any philosophical > objection to an approach like that? > No problems. Classpathx would be a possible place to do it. I'd suggest thinking twice about what this involves in practical terms. You would be wanting to revive the 2.0 API while Sun is at 3.0 and grandfathering the JSR. This undermines the main reason (established api) for using the javax.comm namespace and does not leave such a project in a good position. The only win I see here is maintaining support for applications that can't migrate namespaces. Not that that isn't important. At some point it is going to be less work to just edit the bytecode :) Such a javax.comm effort would also be signing up new projects that decided to use the work up for concerns they probably will not understand or expect. That probably isn't a good path to facilitate for new projects at this time. We will put a good faith effort to work well with others but keep in mind the project has limited bandwidth for such efforts. > Of course, I suspect it might be better if someone with that authority at Sun > would admit that the javax namespace is already in the wild and that there is > no problem with it being used within RXTX. > > Jim > > Trent Jarvi wrote: >> Hi Jim, >> >> I will not step into the javax.comm namespace without Sun's explicite >> permission. I fully understand the pain point you are trying to address. >> >> In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java >> Comm Linux) - which remains an integral part of rxtx. At the time it was a >> win for Sun and rxtx. >> >> The Sun commapi license is/was fairly clear that rxtx should not step into >> that namespace. It made sense as Sun was active in that space and rxtx may >> go into another namespace - it was an experiment in working with Sun. >> >> This may sound silly looking at something that happened almost 10 years >> ago. In a community of respect which Sun helped create, there is no >> question about what to do. I hope eventually Sun will step up and do a >> right thing too. >> >> I agree that this is hurting the API more than helping it. There are also >> questions about how to replace the API in the long term which includes HID >> support which isn't going well so far. >> >> Others that can't even look at Sun's javax.comm today and can look at >> Kaffe's contribution to classpathx can easily work around such >> restrictions. >> >> On Mon, 4 Aug 2008, Jim Redman wrote: >> >>> Has there been any work/would it be possible, to layer a javacomm >>> look-alike on top of the GNU code? >>> >>> The goal is not to move the javax code forward, but to emulate the >>> "legacy" javax packages for people who still need this. >>> >>> Jim >>> >>> Trent Jarvi wrote: >>>> It would be nice to work with Sun to resolve those longstanding issues. >>>> But it may not be practical unless the process goes as fast and painless >>>> as the grandfathering of commapi did. >>>> >>>> Another option may be the old kaffe extensions that moved to gnu >>>> classpathx. These don't have the native libraries but should provide >>>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>>> >>>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From sandeep at genevasoftech.com Wed Aug 6 00:03:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Wed, 06 Aug 2008 11:33:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: <48993EB8.30107@genevasoftech.com> Thank you Mr. Martin for your suggestion. The native file which is given in rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am getting the following error . Any suggestions to solve this issue. I am using Solaris SPARC 64 bit machine. ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) thrown while loading gnu.io.RXTXCommDriver Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(Unknown Source) at java.lang.ClassLoader.loadLibrary(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) at com.ReadFromModem.main(ReadFromModem.java:84) * * *Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid > that then > you're out of luck since I think that quite a bit of RXTX is not yet ready > for 64 bit. > > Cheers, > -- > *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > ------------------------------------------------------------------------ > *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On > Behalf Of *Sandeep Kumar K > *Sent:* Tuesday, August 05, 2008 7:19 PM > *To:* rxtx at qbang.org > *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so > for Solaris 9 > > Hi, > > Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 > bit machine. The librxtxSerial.so given in website is for Solaris 8. > > *-- > > Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/1e920343/attachment.html From tjarvi at qbang.org Wed Aug 6 00:21:42 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 00:21:42 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <48993EB8.30107@genevasoftech.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> <48993EB8.30107@genevasoftech.com> Message-ID: Hi Sandeep You may be out of luck unless you can compile the 2.1 src in CVS (requires gnu make and gcc). But you could try the ToyBox(R)(TM) which is a collection of WiLdLy untested cross compiled 2.1-7 binaries covering everything from the ibm z series to embeded arm/ppc. To give an idea how poorly these are tested, I don't even know if z series machines have a serial port. ftp://www.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Solaris They should at least match the binary types. Actually, I think if you use the rxtx jar from CVS with that file, it should 'work' as the fix for 64 bits was in java not the native code. You could just cd rxtx*/src; javac *.java then jar -cf RXTXcomm.jar `find -name \*.class` to create the hybrid which will complain about version information a bit. On Wed, 6 Aug 2008, Sandeep Kumar K wrote: > Thank you Mr. Martin for your suggestion. The native file which is given in > rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am > getting the following error . > Any suggestions to solve this issue. > I am using Solaris SPARC 64 bit machine. > > ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar > java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 > (Possible cause: architecture word > width mismatch) thrown while loading gnu.io.RXTXCommDriver > Exception in thread "main" java.lang.UnsatisfiedLinkError: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF > class: ELFCLASS64 (Possible cause: > architecture word width mismatch) > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(Unknown Source) > at java.lang.ClassLoader.loadLibrary(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > at com.ReadFromModem.main(ReadFromModem.java:84) > > * > * > > *Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > > > Oberhuber, Martin wrote: >> Sandeep, >> shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse >> variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on >> Sol7 but I've successfully run it on Sol9 and Sol10. >> Or is your request really about a native 64bit variant? I'm afraid that >> then >> you're out of luck since I think that quite a bit of RXTX is not yet ready >> for 64 bit. >> Cheers, >> -- >> *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> ------------------------------------------------------------------------ >> *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On >> Behalf Of *Sandeep Kumar K >> *Sent:* Tuesday, August 05, 2008 7:19 PM >> *To:* rxtx at qbang.org >> *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so >> for Solaris 9 >> >> Hi, >> >> Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 >> bit machine. The librxtxSerial.so given in website is for Solaris 8. >> >> *-- >> Thanks & Regards >> >> Sandeep Kumar K >> Sr. Software Engineer >> Geneva Software Technologies >> Whitefield, Bangalore >> Mob : 9880193454* >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> From michael.erskine at ketech.com Wed Aug 6 01:39:28 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 6 Aug 2008 08:39:28 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Florian Manschwetus wrote: > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) Hi Florian, I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. Regards, Michael Erskine. From florianmanschwetus at gmx.de Wed Aug 6 02:53:16 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 06 Aug 2008 10:53:16 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Message-ID: <4899667C.6010706@gmx.de> Michael Erskine schrieb: > Florian Manschwetus wrote: >> Ok, sounds fine for the receiving problem. >> But why i have to wait after each byte when sending a command squence? >> (the for loop in send command) > > Hi Florian, > I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. > > Regards, > Michael Erskine. > correct with a terminal on the other end it works, my idea was that this basic baud has some influence. Could some one explain what it is for? Florian > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/c2b4fa84/attachment-0001.bin From rick_knight at rlknight.com Mon Aug 4 13:25:10 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Mon, 04 Aug 2008 12:25:10 -0700 Subject: [Rxtx] Sun's Comm API? Message-ID: <48975796.4010600@rlknight.com> I have an application that requires the javax compatible version of RXTX and Sun's comm api. I've been able to download and extract the version of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api anywhere. Can someone tell me where I can find it? Or maybe send me a copy? Also, when I try to build RXTX, configure and make complete successfully but make install failes with this error libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 I've never come accross this error before. How can I get past it? Thanks, Rick From bboyes at systronix.com Mon Aug 4 19:10:01 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:10:01 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48975796.4010600@rlknight.com> References: <48975796.4010600@rlknight.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/cb9c6167/attachment-0003.html From bboyes at systronix.com Mon Aug 4 19:12:37 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:12:37 -0600 Subject: [Rxtx] Towards an RXTX release - CSR BT/USB chipset In-Reply-To: <488FB7E7.8000802@gmail.com> References: <460801A4097E3D4CA04CC64EE648584806C56CF0@ism-mail03.corp.ad.wrs.com> <13557-75390@sneakemail.com> <20980-23424@sneakemail.com> <488FB7E7.8000802@gmail.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/52236088/attachment-0003.html From tjarvi at qbang.org Mon Aug 4 19:42:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 19:42:21 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: On Mon, 4 Aug 2008, Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: > I have an application that requires the javax compatible > version of RXTX > and Sun's comm api. I've been able to download and extract > the version > of RXTX that I need (2.0-7pre2) but I can't find Sun's camm > api > anywhere. Can someone tell me where I can find it? Or maybe > send me a > > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm port > support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have just > a ZIP with only the .class JAR file - no source or docs), has a readme > with these comments: > > This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release.? The 2.0.3 release itself is > no longer distributed.? comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project.? The RxTx project (http://www.rxtx.org ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org) was opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support.? Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins.? Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > ? > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > I hope that is helpful! > It would be nice to work with Sun to resolve those longstanding issues. But it may not be practical unless the process goes as fast and painless as the grandfathering of commapi did. Another option may be the old kaffe extensions that moved to gnu classpathx. These don't have the native libraries but should provide the 2.0 interface and the javax.comm.properties mechansim for SPI. http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Mon Aug 4 20:23:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Mon, 04 Aug 2008 20:23:57 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4897B9BD.5070809@ergotech.com> Has there been any work/would it be possible, to layer a javacomm look-alike on top of the GNU code? The goal is not to move the javax code forward, but to emulate the "legacy" javax packages for people who still need this. Jim Trent Jarvi wrote: > On Mon, 4 Aug 2008, Bruce Boyes wrote: > >> At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible >> version of RXTX >> and Sun's comm api. I've been able to download and extract >> the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm >> api >> anywhere. Can someone tell me where I can find it? Or maybe >> send me a >> >> >> javaxcomm has had a sort of on-again off-again history. The windoze >> version has been languishing for years (literally) but there are newer >> versions for other OS's. >> >> We try to keep links on one of our help pages current: >> http://www.practicalembeddedjava.com/tools/javatools_list.html >> which gets you to here: >> http://java.sun.com/products/javacomm/ >> where it says in fact they no longer even support Windows and Mac: >> "Implementations of the API are currently available for Solaris SPARC, >> Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so >> someone could support it. But I guess that's part of the reason RXTX >> exists! >> >> So one of Sun's own products, SunSPOT, has to use RXTX to get comm port >> support. >> >> The version we use is 2.0 from 11/15/1998. I have posted it on our >> website, which is within the terms of the license agreement contained >> therein (as I understand it). >> >> The last version of javaxcomm for Windows, 2.0.3, (for which I have just >> a ZIP with only the .class JAR file - no source or docs), has a readme >> with these comments: >> >> This distribution contains the comm.jar file original part >> of the COMMAPI 2.0.3 release. The 2.0.3 release itself is >> no longer distributed. comm.jar, which contains the comm >> API java class files (eg. Sun's binary implementation of the >> interface classes), is being made available, unsupported, >> with no obligation to fix bugs, at the request of the RXTX >> project. The RxTx project (http://www.rxtx.org ), uses the >> comm.jar class files, but provides their own native library >> components to provide support for other platforms. >> >> The 2.0.3 comm.jar is being provided in this way because >> as of COMMAPI 3.x, the java binary implementation forked and >> became incompatible with the RxTx project's native code. >> Due to the lack of a clear business case, and to resource >> constraints, no additional resources are being >> provided to provide an alternative engineering solution >> at the time of writing. >> >> RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: >> >> Ultimately the COMMAPI would be better served if a Java >> Community Process JSR (http://www.jcp.org) was opened and >> the COMMAPI was rearchitected to provide a more pluggable >> framework to improve cross-platform support. Such an >> architecture would embody a better defined and better >> documented SPI interface, including a way for comm. ports >> to be revealed to the client application through the API >> via platform-aware plugins. Similarly, native code used >> to access comm port in general could be handled more >> flexibly using a plugin model, whereby on any platform, >> multiple native modules could be in use simultaneously. >> >> Since there are now various ways serial ports can be implemented >> and accessed, modular comm. port JNI native libraries would be >> of benefit insofar as removing the burden of over-generalization >> from any single native component, or inversely, by relieving the >> implicit constraint that comm. drivers be accessed only via a >> monolithic mechanism, such as the UNIX vnode interface. >> >> paul.klissner at sun.com >> 6/10/06 >> >> I hope that is helpful! >> > > It would be nice to work with Sun to resolve those longstanding issues. > But it may not be practical unless the process goes as fast and painless > as the grandfathering of commapi did. > > Another option may be the old kaffe extensions that moved to gnu > classpathx. These don't have the native libraries but should provide > the 2.0 interface and the javax.comm.properties mechansim for SPI. > > http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Mon Aug 4 21:09:15 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 21:09:15 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? Message-ID: Hi Jim, I will not step into the javax.comm namespace without Sun's explicite permission. I fully understand the pain point you are trying to address. In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm Linux) - which remains an integral part of rxtx. At the time it was a win for Sun and rxtx. The Sun commapi license is/was fairly clear that rxtx should not step into that namespace. It made sense as Sun was active in that space and rxtx may go into another namespace - it was an experiment in working with Sun. This may sound silly looking at something that happened almost 10 years ago. In a community of respect which Sun helped create, there is no question about what to do. I hope eventually Sun will step up and do a right thing too. I agree that this is hurting the API more than helping it. There are also questions about how to replace the API in the long term which includes HID support which isn't going well so far. Others that can't even look at Sun's javax.comm today and can look at Kaffe's contribution to classpathx can easily work around such restrictions. On Mon, 4 Aug 2008, Jim Redman wrote: > Has there been any work/would it be possible, to layer a javacomm > look-alike on top of the GNU code? > > The goal is not to move the javax code forward, but to emulate the > "legacy" javax packages for people who still need this. > > Jim > > Trent Jarvi wrote: >> >> It would be nice to work with Sun to resolve those longstanding issues. >> But it may not be practical unless the process goes as fast and painless >> as the grandfathering of commapi did. >> >> Another option may be the old kaffe extensions that moved to gnu >> classpathx. These don't have the native libraries but should provide >> the 2.0 interface and the javax.comm.properties mechansim for SPI. >> >> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From florianmanschwetus at gmx.de Tue Aug 5 05:04:46 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 13:04:46 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: References: <48971C1F.9020806@gmx.de> Message-ID: <489833CE.1040801@gmx.de> Just look at sendCommand in this method I have to place a Thread.sleep(20) after each byte send to get working. Even the event based receive doesn't work fine but this could be may stupidness. The specifikation document (it is on the last pages of the manual) for the beamer could be found on: http://www.optoma.co.uk/support.aspx Florian Manschwetus Trent Jarvi schrieb: > > Hi Florian > > Sorry for the top post in advance. I worry you may not see my answer > under all your code :) > > I have not received this email before. This is 500k of code which I > don't have time to read. I can spend about 5 min on each hobby email > and still get to work in the morning. I have a couple suggestions for > how to get an answer. > > First, cut out your comments and extra code so you can demonstrate the > question (I might even glance and see what is wrong then). Don't go for > a working final product. Isolate the problem using a simple program and > then ask with that as an example. If I did what you just did, I'd have > to post 3/4 of a million lines of code :) > > Second, join the rxtx mail-list and ask there. This will give you 100x > more eyes. I'll also read and try to follow. > > -- > taj > > > > On Mon, 4 Aug 2008, Florian Manschwetus wrote: > >> It could be that my university account is blocked by filters so >> resending from here. >> >> >> Topic is to control Optoma HD80 beamer using rs232 serial chat. >> This code is able to detect power state and switch the beamer on / off. >> connected is the beamer using a digitus usb 2.0 serial adapter with an >> FT232 USB-Serial adapter the systems architecture is amd64. >> >> Please take a look in the sendCommand routine i have to place theire >> those Thread.sleep to get it working. >> Now the question is this correct or is there a better way to get this >> working correctly? >> >> In the javadoc coming with the install i found this: >> setBaudBase >> >> public boolean setBaudBase(int BaudBase) >> throws UnsupportedCommOperationException, >> java.io.IOException >> >> Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 >> before using. >> >> could this explain the error? >> I attached my java source and the protocol description for the beamer >> (available on vendor website). >> >> thx, >> Florian Manschwetus >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: TestRS232.java Type: text/x-java Size: 9143 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0006.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0007.bin From michael.erskine at ketech.com Tue Aug 5 05:53:49 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Tue, 5 Aug 2008 12:53:49 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489833CE.1040801@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> > Just look at sendCommand in this method I have to place a > Thread.sleep(20) after each byte send to get working. Even the event > based receive doesn't work fine but this could be may stupidness. Hi Florian, Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. Regards, Michael Erskine. From florianmanschwetus at gmx.de Tue Aug 5 07:28:15 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:28:15 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> Message-ID: <4898556F.8000208@gmx.de> Michael Erskine schrieb: >> Just look at sendCommand in this method I have to place a >> Thread.sleep(20) after each byte send to get working. Even the event >> based receive doesn't work fine but this could be may stupidness. > > Hi Florian, > > Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. > > Regards, > Michael Erskine. > Ok, sounds fine for the receiving problem. But why i have to wait after each byte when sending a command squence? (the for loop in send command) Florian > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/284f350c/attachment-0002.bin From florianmanschwetus at gmx.de Tue Aug 5 07:44:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:44:14 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <4898592E.2020908@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >>> Just look at sendCommand in this method I have to place a >>> Thread.sleep(20) after each byte send to get working. Even the event >>> based receive doesn't work fine but this could be may stupidness. >> >> Hi Florian, >> >> Yes, naturally you'll have to wait for a response from the other end. >> Why not wait for notification from the event thread perhaps using a >> BlockingDeque rather than your LinkedList. Generally I >> try to decouple all input and output streams: in your case your >> application is operating synchronously like the "expect" program >> (http://expect.nist.gov/) so waits (or timeouts) will need to be >> factored in. >> >> Regards, >> Michael Erskine. >> > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) > > Florian Furthermore there is this basic baud with this confusing javadoc entry: public boolean setBaudBase(int BaudBase) throws UnsupportedCommOperationException, java.io.IOException Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 before using. maybe this could explain something Florian >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/006c7425/attachment-0002.bin From jredman at ergotech.com Tue Aug 5 09:13:36 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 05 Aug 2008 09:13:36 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: Message-ID: <48986E20.3060104@ergotech.com> Trent, So two issues: 1) Technically I'm still not sure how easy/practical a layer would be. The problems are always classes like listeners, and wrapping returns of gnu.io classes. I really see it as a "delegate" type of concept. Any thoughts or ideas of the practicality of this approach? The idea is not to modify RXTX. 2) Javax. The javax namespace does seem to be in widespread use outside of Sun (the same is true for the java namespace). The classpath extensions, or some other location, should be interested in a JavaComm implementation even if it does have dependencies on RXTX. Would you have any philosophical objection to an approach like that? Of course, I suspect it might be better if someone with that authority at Sun would admit that the javax namespace is already in the wild and that there is no problem with it being used within RXTX. Jim Trent Jarvi wrote: > Hi Jim, > > I will not step into the javax.comm namespace without Sun's explicite > permission. I fully understand the pain point you are trying to address. > > In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm > Linux) - which remains an integral part of rxtx. At the time it was a win for > Sun and rxtx. > > The Sun commapi license is/was fairly clear that rxtx should not step into that > namespace. It made sense as Sun was active in that space and rxtx may go into > another namespace - it was an experiment in working with Sun. > > This may sound silly looking at something that happened almost 10 years ago. > In a community of respect which Sun helped create, there is no question about > what to do. I hope eventually Sun will step up and do a right thing too. > > I agree that this is hurting the API more than helping it. There are also > questions about how to replace the API in the long term which includes HID > support which isn't going well so far. > > Others that can't even look at Sun's javax.comm today and can look at Kaffe's > contribution to classpathx can easily work around such restrictions. > > On Mon, 4 Aug 2008, Jim Redman wrote: > >> Has there been any work/would it be possible, to layer a javacomm >> look-alike on top of the GNU code? >> >> The goal is not to move the javax code forward, but to emulate the >> "legacy" javax packages for people who still need this. >> >> Jim >> >> Trent Jarvi wrote: >>> It would be nice to work with Sun to resolve those longstanding issues. >>> But it may not be practical unless the process goes as fast and painless >>> as the grandfathering of commapi did. >>> >>> Another option may be the old kaffe extensions that moved to gnu >>> classpathx. These don't have the native libraries but should provide >>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>> >>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From sandeep at genevasoftech.com Tue Aug 5 11:18:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Tue, 05 Aug 2008 22:48:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <48988B6C.5080409@genevasoftech.com> Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. *-- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/ad20f1cb/attachment-0002.html From Martin.Oberhuber at windriver.com Tue Aug 5 13:30:17 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Tue, 5 Aug 2008 21:30:17 +0200 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Sandeep, shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on Sol7 but I've successfully run it on Sol9 and Sol10. Or is your request really about a native 64bit variant? I'm afraid that then you're out of luck since I think that quite a bit of RXTX is not yet ready for 64 bit. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Sandeep Kumar K Sent: Tuesday, August 05, 2008 7:19 PM To: rxtx at qbang.org Subject: [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so for Solaris 9 Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. -- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/81b7f988/attachment-0002.html From tjarvi at qbang.org Tue Aug 5 22:38:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 22:38:34 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 5 Aug 2008, Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built > on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid that > then > you're out of luck since I think that quite a bit of RXTX is not yet > ready > for 64 bit. > While rxtx-2.1-7 probably has problems, The CVS code should be OK for 64 bit Solaris. If it isn't, let me know and I'll find which patch is missing. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Aug 5 23:13:00 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 23:13:00 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48986E20.3060104@ergotech.com> References: <48986E20.3060104@ergotech.com> Message-ID: On Tue, 5 Aug 2008, Jim Redman wrote: > Trent, > > So two issues: > > 1) Technically I'm still not sure how easy/practical a layer would be. The > problems are always classes like listeners, and wrapping returns of gnu.io > classes. I really see it as a "delegate" type of concept. Any thoughts or > ideas of the practicality of this approach? The idea is not to modify RXTX. I have not put too much thought into this. I assume you want what rxtx 2.0 provided to tie into javax.comm implementations. More classes could be added to rxtx 2.1-7 for SPI support. Maintaining rxtx-2.0 could also be handed to someone if they like. > > 2) Javax. The javax namespace does seem to be in widespread use outside of > Sun (the same is true for the java namespace). The classpath extensions, or > some other location, should be interested in a JavaComm implementation even > if it does have dependencies on RXTX. Would you have any philosophical > objection to an approach like that? > No problems. Classpathx would be a possible place to do it. I'd suggest thinking twice about what this involves in practical terms. You would be wanting to revive the 2.0 API while Sun is at 3.0 and grandfathering the JSR. This undermines the main reason (established api) for using the javax.comm namespace and does not leave such a project in a good position. The only win I see here is maintaining support for applications that can't migrate namespaces. Not that that isn't important. At some point it is going to be less work to just edit the bytecode :) Such a javax.comm effort would also be signing up new projects that decided to use the work up for concerns they probably will not understand or expect. That probably isn't a good path to facilitate for new projects at this time. We will put a good faith effort to work well with others but keep in mind the project has limited bandwidth for such efforts. > Of course, I suspect it might be better if someone with that authority at Sun > would admit that the javax namespace is already in the wild and that there is > no problem with it being used within RXTX. > > Jim > > Trent Jarvi wrote: >> Hi Jim, >> >> I will not step into the javax.comm namespace without Sun's explicite >> permission. I fully understand the pain point you are trying to address. >> >> In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java >> Comm Linux) - which remains an integral part of rxtx. At the time it was a >> win for Sun and rxtx. >> >> The Sun commapi license is/was fairly clear that rxtx should not step into >> that namespace. It made sense as Sun was active in that space and rxtx may >> go into another namespace - it was an experiment in working with Sun. >> >> This may sound silly looking at something that happened almost 10 years >> ago. In a community of respect which Sun helped create, there is no >> question about what to do. I hope eventually Sun will step up and do a >> right thing too. >> >> I agree that this is hurting the API more than helping it. There are also >> questions about how to replace the API in the long term which includes HID >> support which isn't going well so far. >> >> Others that can't even look at Sun's javax.comm today and can look at >> Kaffe's contribution to classpathx can easily work around such >> restrictions. >> >> On Mon, 4 Aug 2008, Jim Redman wrote: >> >>> Has there been any work/would it be possible, to layer a javacomm >>> look-alike on top of the GNU code? >>> >>> The goal is not to move the javax code forward, but to emulate the >>> "legacy" javax packages for people who still need this. >>> >>> Jim >>> >>> Trent Jarvi wrote: >>>> It would be nice to work with Sun to resolve those longstanding issues. >>>> But it may not be practical unless the process goes as fast and painless >>>> as the grandfathering of commapi did. >>>> >>>> Another option may be the old kaffe extensions that moved to gnu >>>> classpathx. These don't have the native libraries but should provide >>>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>>> >>>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From sandeep at genevasoftech.com Wed Aug 6 00:03:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Wed, 06 Aug 2008 11:33:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: <48993EB8.30107@genevasoftech.com> Thank you Mr. Martin for your suggestion. The native file which is given in rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am getting the following error . Any suggestions to solve this issue. I am using Solaris SPARC 64 bit machine. ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) thrown while loading gnu.io.RXTXCommDriver Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(Unknown Source) at java.lang.ClassLoader.loadLibrary(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) at com.ReadFromModem.main(ReadFromModem.java:84) * * *Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid > that then > you're out of luck since I think that quite a bit of RXTX is not yet ready > for 64 bit. > > Cheers, > -- > *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > ------------------------------------------------------------------------ > *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On > Behalf Of *Sandeep Kumar K > *Sent:* Tuesday, August 05, 2008 7:19 PM > *To:* rxtx at qbang.org > *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so > for Solaris 9 > > Hi, > > Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 > bit machine. The librxtxSerial.so given in website is for Solaris 8. > > *-- > > Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/1e920343/attachment-0002.html From tjarvi at qbang.org Wed Aug 6 00:21:42 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 00:21:42 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <48993EB8.30107@genevasoftech.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> <48993EB8.30107@genevasoftech.com> Message-ID: Hi Sandeep You may be out of luck unless you can compile the 2.1 src in CVS (requires gnu make and gcc). But you could try the ToyBox(R)(TM) which is a collection of WiLdLy untested cross compiled 2.1-7 binaries covering everything from the ibm z series to embeded arm/ppc. To give an idea how poorly these are tested, I don't even know if z series machines have a serial port. ftp://www.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Solaris They should at least match the binary types. Actually, I think if you use the rxtx jar from CVS with that file, it should 'work' as the fix for 64 bits was in java not the native code. You could just cd rxtx*/src; javac *.java then jar -cf RXTXcomm.jar `find -name \*.class` to create the hybrid which will complain about version information a bit. On Wed, 6 Aug 2008, Sandeep Kumar K wrote: > Thank you Mr. Martin for your suggestion. The native file which is given in > rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am > getting the following error . > Any suggestions to solve this issue. > I am using Solaris SPARC 64 bit machine. > > ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar > java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 > (Possible cause: architecture word > width mismatch) thrown while loading gnu.io.RXTXCommDriver > Exception in thread "main" java.lang.UnsatisfiedLinkError: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF > class: ELFCLASS64 (Possible cause: > architecture word width mismatch) > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(Unknown Source) > at java.lang.ClassLoader.loadLibrary(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > at com.ReadFromModem.main(ReadFromModem.java:84) > > * > * > > *Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > > > Oberhuber, Martin wrote: >> Sandeep, >> shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse >> variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on >> Sol7 but I've successfully run it on Sol9 and Sol10. >> Or is your request really about a native 64bit variant? I'm afraid that >> then >> you're out of luck since I think that quite a bit of RXTX is not yet ready >> for 64 bit. >> Cheers, >> -- >> *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> ------------------------------------------------------------------------ >> *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On >> Behalf Of *Sandeep Kumar K >> *Sent:* Tuesday, August 05, 2008 7:19 PM >> *To:* rxtx at qbang.org >> *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so >> for Solaris 9 >> >> Hi, >> >> Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 >> bit machine. The librxtxSerial.so given in website is for Solaris 8. >> >> *-- >> Thanks & Regards >> >> Sandeep Kumar K >> Sr. Software Engineer >> Geneva Software Technologies >> Whitefield, Bangalore >> Mob : 9880193454* >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> From michael.erskine at ketech.com Wed Aug 6 01:39:28 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 6 Aug 2008 08:39:28 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Florian Manschwetus wrote: > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) Hi Florian, I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. Regards, Michael Erskine. From florianmanschwetus at gmx.de Wed Aug 6 02:53:16 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 06 Aug 2008 10:53:16 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Message-ID: <4899667C.6010706@gmx.de> Michael Erskine schrieb: > Florian Manschwetus wrote: >> Ok, sounds fine for the receiving problem. >> But why i have to wait after each byte when sending a command squence? >> (the for loop in send command) > > Hi Florian, > I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. > > Regards, > Michael Erskine. > correct with a terminal on the other end it works, my idea was that this basic baud has some influence. Could some one explain what it is for? Florian > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/c2b4fa84/attachment-0002.bin From rick_knight at rlknight.com Wed Aug 6 13:01:07 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:01:07 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F4F3.3020707@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > I have an application (Readerware) that uses RXTX with Javax to access the serial port. This used to work fine under previous Linux' and Java, but something has changed, I assume with Java itself , that is causing the application to fail with a link error. The application is not able to find librxtxSerialParallel.so. RXTX supplies librxtxSerial.so and librxtxParallel.so, but not librxtxSerialParallel.so. Where can I get librxtxSerialParallel.so, or do I need it? Is something else causing the lib to not be found? Thanks, Rick Knight From rick_knight at rlknight.com Wed Aug 6 13:17:55 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:17:55 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F8E3.5060400@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Thanks for the reply. The developer of the app I'm trying to use (Readerware) has sent me a copy of the comm.api and I've copied the library (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar into the proper places. When I try to run the application, I get this error... Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: /usr/lib/libSolarisSerialParallel.so: /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not little-endian (Possible cause: endianness mismatch) Caught java.lang.UnsatisfiedLinkError: com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I while loading driver com.sun.comm.SolarisDriver Is there a way around this error? Thanks again, Rick Knight From jlar310 at gmail.com Wed Aug 6 13:37:42 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 14:37:42 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899F8E3.5060400@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > The developer of the app I'm trying to use (Readerware) has sent me a > copy of the comm.api and I've copied the library > (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar > into the proper places. When I try to run the application, I get this > error... > > Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: > /usr/lib/libSolarisSerialParallel.so: > /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not > little-endian (Possible cause: endianness mismatch) > Caught java.lang.UnsatisfiedLinkError: > com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I > > while loading driver com.sun.comm.SolarisDriver > > Is there a way around this error? What host OS are you running? From your original post it looks like 32 bit Linux. The libSolarisSerialParallel.so file is for Sun Solaris and will vary depending on the underlying hardware architecture as well. Sorry for the double post Rick, but I failed to send this to the list the first time... -- Jeff From rick_knight at rlknight.com Wed Aug 6 13:44:29 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:44:29 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: <4899FF1D.9030504@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > > >> The developer of the app I'm trying to use (Readerware) has sent me a >> copy of the comm.api and I've copied the library >> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >> into the proper places. When I try to run the application, I get this >> error... >> >> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >> /usr/lib/libSolarisSerialParallel.so: >> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >> little-endian (Possible cause: endianness mismatch) >> Caught java.lang.UnsatisfiedLinkError: >> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >> >> while loading driver com.sun.comm.SolarisDriver >> >> Is there a way around this error? >> > > What host OS are you running? From your original post it looks like 32 > bit Linux. > > The libSolarisSerialParallel.so file is for Sun Solaris and will vary > depending on the underlying hardware architecture as well. > > I'm running Kubuntu Linux (debian based). It's 32 bit. Rick Knight From jlar310 at gmail.com Wed Aug 6 15:33:23 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 16:33:23 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > I don't think Sun did binary libraries for Linux in the 2.0 version. Can someone with more historical experience than I confirm that? I recently tried to port a Comm API application from Solaris sparc to Linux x86 and likewise could not get my hands on the binary libraries. I eventually just re-wrote the code to use the gnu namespace packages and rxtx 2.1. What I don't understand is why your application vendor does not provide everything you need to run their software. FYI: I have librxtxParallel.so and librxtxSerial.so installed at JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is /usr/java/default which is actually a softlink to /usr/java/jre1.6.0_05. -- Jeff From defiantlew at yahoo.com.au Wed Aug 6 16:29:33 2008 From: defiantlew at yahoo.com.au (Lew L) Date: Thu, 7 Aug 2008 08:29:33 +1000 Subject: [Rxtx] Sun's Comm API Documentation References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> Message-ID: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> As a matter of interest is the Sun Comm API documentation available somewhere? I have tried the Sun site but it seems to have been removed. Unless I have missed the documentation for RXTX? I javadocced the RXTX source but information (to me) is minimal. Somewhere I got the impression that the Sun Comm API docs is, or was, compatible with RXTX, what is the best docs to use in conjuntion with RXTX and where may the be available? Cheers Lew From rick_knight at rlknight.com Wed Aug 6 17:18:33 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:18:33 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A3149.4050306@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff I'm not sure if I posted this here or not, but when I try to build RXTX from source I get this install error... make all-am make[1]: Entering directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' make[1]: Nothing to be done for `all-am'. make[1]: Leaving directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 Can you tell me how to get past this error and get RXTX built and installed? Thanks, Rick From bboyes at systronix.com Wed Aug 6 17:40:12 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Wed, 06 Aug 2008 17:40:12 -0600 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: At 16:29 08/06/2008, Lew L wrote: >As a matter of interest is the Sun Comm API documentation available >somewhere? I have tried the Sun site but it seems to have been removed. It's in the file we have posted, link in prev email (sorry, in a huge hurry right now). Javadocs definitely there. >Unless I have missed the documentation for RXTX? I javadocced the RXTX >source but information (to me) is minimal. >Somewhere I got the impression that the Sun Comm API docs is, or was, >compatible with RXTX, what is the best docs to use in conjuntion with RXTX >and where may the be available? Yeah, this is one of my concerns/beefs. There is little documentation for RXTX and it isn't just the same as javaxcomm. I would be willing to help out writing docs for RXTX! Yes really... esp if we can fix the Bluetooth issues. best regards Bruce >Cheers >Lew > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx ------- WWW.SYSTRONIX.COM ---------- Real embedded Java and much more +1-801-534-1017 Salt Lake City, USA From rick_knight at rlknight.com Wed Aug 6 17:54:08 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:54:08 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A39A0.2090309@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff, I would like for my vendor to switch to rxtx 2.1. It would make things much easier for me. I'm not sure why he's still using the javax compatible code. He's a small operation. Re-writing the code to use gnu namespace sounds like a major overhaul. Was it? Thanks, Rick From tjarvi at qbang.org Wed Aug 6 21:35:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:35:12 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: >> >>> Jeff wrote: >>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>>> >>>> >>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things > much easier for me. I'm not sure why he's still using the javax > compatible code. He's a small operation. Re-writing the code to use gnu > namespace sounds like a major overhaul. Was it? > Hi Jeff, The changes are fairly mechanical. Imports need to change and any explicite use of the namespace needs to change such as catching an exception. The following script was made for maintaining rxtx 2.0 but can apply to other needs. It is in the contrib dir with rxtx source. #!/bin/sh # Don't use! :) # # Sat, 03 May 2003 16:45:08 Modifications from J?rg Weule # Create a ed-cmd for the change of one pattern # case $1 in gnu) X=g/javax_comm/s+javax_comm+gnu_io+g ;; javax) X=g/gnu_io/s+gnu_io+javax_comm+g ;; *) echo;echo;echo From the top rxtx directory run;echo;echo -e \\t./ChangePackage.sh gnu;echo -e \\t\\tor;echo -e \\t./ChangePackage.sh javax;echo;echo; exit 0 ;; esac # # ed will be used to keep the owner and mode of the files unchanged. # We have run the ed-script for the characters '.' '/' as well. # "tr _ $D" do the change. # find . -type f -a -print | grep -v $0 | (while read F ; do ( echo $X; echo $X| tr _ /; echo $X| tr _ .; echo w; echo q ) | ed $F 2>&1 >/dev/null done ) # # Now we do little changes at the Makefiles. Hope that all we need. # find . -name Makefile\* -a -print | (while read F ; do cat < References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: On Thu, 7 Aug 2008, Lew L wrote: > As a matter of interest is the Sun Comm API documentation available > somewhere? I have tried the Sun site but it seems to have been removed. > > Unless I have missed the documentation for RXTX? I javadocced the RXTX > source but information (to me) is minimal. > Somewhere I got the impression that the Sun Comm API docs is, or was, > compatible with RXTX, what is the best docs to use in conjuntion with RXTX > and where may the be available? > Hi Lew, The documentation on Sun's website is accurate. The changes that are problematic in 3.0 are on the backside which rxtx used to plug into. http://java.sun.com/products/javacomm/reference/api/index.html CommPortIdentifier may have some minor differences (judging by the authors notes). -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Aug 6 21:46:08 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:46:08 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > If javax.comm.properties is properly installed and you are using a 2.0 version of Sun's commapi with rxtx 2.0, you should not see the library attempt to load libSolarisSerialParallel.so. Sun CommAPI 3.0 will not work with any version of rxtx as it is hard coded to use the shared library. See the INSTALL file with rxtx-2.0 source for more help with the properties file. -- Trent Jarvi tjarvi at qbang.org From jlar310 at gmail.com Thu Aug 7 06:32:06 2008 From: jlar310 at gmail.com (Jeff) Date: Thu, 7 Aug 2008 07:32:06 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > Jeff wrote: >> >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >> wrote: >> >>> >>> Jeff wrote: >>> >>>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>> wrote: >>>> >>>> >>>> >>>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things much > easier for me. I'm not sure why he's still using the javax compatible code. > He's a small operation. Re-writing the code to use gnu namespace sounds like > a major overhaul. Was it? I found it quite easy. In fact, in order to accommodate the transition, I actually separated all of the code that deals directly with the Comm API or RXTX into a helper class. The helper class was then coded to use reflection to determine which library was available and then instantiate the necessary objects. No direct imports of either library are used. The main application just needs to get it's hands on the IO streams and need not deal directly with the libraries. Other programs may not be so simple... But this doesn't really help you unless your vendor forks over the source code... -- Jeff From rick_knight at rlknight.com Mon Aug 4 13:25:10 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Mon, 04 Aug 2008 12:25:10 -0700 Subject: [Rxtx] Sun's Comm API? Message-ID: <48975796.4010600@rlknight.com> I have an application that requires the javax compatible version of RXTX and Sun's comm api. I've been able to download and extract the version of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api anywhere. Can someone tell me where I can find it? Or maybe send me a copy? Also, when I try to build RXTX, configure and make complete successfully but make install failes with this error libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 I've never come accross this error before. How can I get past it? Thanks, Rick From bboyes at systronix.com Mon Aug 4 19:10:01 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:10:01 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48975796.4010600@rlknight.com> References: <48975796.4010600@rlknight.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/cb9c6167/attachment-0004.html From bboyes at systronix.com Mon Aug 4 19:12:37 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:12:37 -0600 Subject: [Rxtx] Towards an RXTX release - CSR BT/USB chipset In-Reply-To: <488FB7E7.8000802@gmail.com> References: <460801A4097E3D4CA04CC64EE648584806C56CF0@ism-mail03.corp.ad.wrs.com> <13557-75390@sneakemail.com> <20980-23424@sneakemail.com> <488FB7E7.8000802@gmail.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/52236088/attachment-0004.html From tjarvi at qbang.org Mon Aug 4 19:42:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 19:42:21 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: On Mon, 4 Aug 2008, Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: > I have an application that requires the javax compatible > version of RXTX > and Sun's comm api. I've been able to download and extract > the version > of RXTX that I need (2.0-7pre2) but I can't find Sun's camm > api > anywhere. Can someone tell me where I can find it? Or maybe > send me a > > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm port > support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have just > a ZIP with only the .class JAR file - no source or docs), has a readme > with these comments: > > This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release.? The 2.0.3 release itself is > no longer distributed.? comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project.? The RxTx project (http://www.rxtx.org ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org) was opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support.? Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins.? Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > ? > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > I hope that is helpful! > It would be nice to work with Sun to resolve those longstanding issues. But it may not be practical unless the process goes as fast and painless as the grandfathering of commapi did. Another option may be the old kaffe extensions that moved to gnu classpathx. These don't have the native libraries but should provide the 2.0 interface and the javax.comm.properties mechansim for SPI. http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Mon Aug 4 20:23:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Mon, 04 Aug 2008 20:23:57 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4897B9BD.5070809@ergotech.com> Has there been any work/would it be possible, to layer a javacomm look-alike on top of the GNU code? The goal is not to move the javax code forward, but to emulate the "legacy" javax packages for people who still need this. Jim Trent Jarvi wrote: > On Mon, 4 Aug 2008, Bruce Boyes wrote: > >> At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible >> version of RXTX >> and Sun's comm api. I've been able to download and extract >> the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm >> api >> anywhere. Can someone tell me where I can find it? Or maybe >> send me a >> >> >> javaxcomm has had a sort of on-again off-again history. The windoze >> version has been languishing for years (literally) but there are newer >> versions for other OS's. >> >> We try to keep links on one of our help pages current: >> http://www.practicalembeddedjava.com/tools/javatools_list.html >> which gets you to here: >> http://java.sun.com/products/javacomm/ >> where it says in fact they no longer even support Windows and Mac: >> "Implementations of the API are currently available for Solaris SPARC, >> Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so >> someone could support it. But I guess that's part of the reason RXTX >> exists! >> >> So one of Sun's own products, SunSPOT, has to use RXTX to get comm port >> support. >> >> The version we use is 2.0 from 11/15/1998. I have posted it on our >> website, which is within the terms of the license agreement contained >> therein (as I understand it). >> >> The last version of javaxcomm for Windows, 2.0.3, (for which I have just >> a ZIP with only the .class JAR file - no source or docs), has a readme >> with these comments: >> >> This distribution contains the comm.jar file original part >> of the COMMAPI 2.0.3 release. The 2.0.3 release itself is >> no longer distributed. comm.jar, which contains the comm >> API java class files (eg. Sun's binary implementation of the >> interface classes), is being made available, unsupported, >> with no obligation to fix bugs, at the request of the RXTX >> project. The RxTx project (http://www.rxtx.org ), uses the >> comm.jar class files, but provides their own native library >> components to provide support for other platforms. >> >> The 2.0.3 comm.jar is being provided in this way because >> as of COMMAPI 3.x, the java binary implementation forked and >> became incompatible with the RxTx project's native code. >> Due to the lack of a clear business case, and to resource >> constraints, no additional resources are being >> provided to provide an alternative engineering solution >> at the time of writing. >> >> RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: >> >> Ultimately the COMMAPI would be better served if a Java >> Community Process JSR (http://www.jcp.org) was opened and >> the COMMAPI was rearchitected to provide a more pluggable >> framework to improve cross-platform support. Such an >> architecture would embody a better defined and better >> documented SPI interface, including a way for comm. ports >> to be revealed to the client application through the API >> via platform-aware plugins. Similarly, native code used >> to access comm port in general could be handled more >> flexibly using a plugin model, whereby on any platform, >> multiple native modules could be in use simultaneously. >> >> Since there are now various ways serial ports can be implemented >> and accessed, modular comm. port JNI native libraries would be >> of benefit insofar as removing the burden of over-generalization >> from any single native component, or inversely, by relieving the >> implicit constraint that comm. drivers be accessed only via a >> monolithic mechanism, such as the UNIX vnode interface. >> >> paul.klissner at sun.com >> 6/10/06 >> >> I hope that is helpful! >> > > It would be nice to work with Sun to resolve those longstanding issues. > But it may not be practical unless the process goes as fast and painless > as the grandfathering of commapi did. > > Another option may be the old kaffe extensions that moved to gnu > classpathx. These don't have the native libraries but should provide > the 2.0 interface and the javax.comm.properties mechansim for SPI. > > http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Mon Aug 4 21:09:15 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 21:09:15 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? Message-ID: Hi Jim, I will not step into the javax.comm namespace without Sun's explicite permission. I fully understand the pain point you are trying to address. In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm Linux) - which remains an integral part of rxtx. At the time it was a win for Sun and rxtx. The Sun commapi license is/was fairly clear that rxtx should not step into that namespace. It made sense as Sun was active in that space and rxtx may go into another namespace - it was an experiment in working with Sun. This may sound silly looking at something that happened almost 10 years ago. In a community of respect which Sun helped create, there is no question about what to do. I hope eventually Sun will step up and do a right thing too. I agree that this is hurting the API more than helping it. There are also questions about how to replace the API in the long term which includes HID support which isn't going well so far. Others that can't even look at Sun's javax.comm today and can look at Kaffe's contribution to classpathx can easily work around such restrictions. On Mon, 4 Aug 2008, Jim Redman wrote: > Has there been any work/would it be possible, to layer a javacomm > look-alike on top of the GNU code? > > The goal is not to move the javax code forward, but to emulate the > "legacy" javax packages for people who still need this. > > Jim > > Trent Jarvi wrote: >> >> It would be nice to work with Sun to resolve those longstanding issues. >> But it may not be practical unless the process goes as fast and painless >> as the grandfathering of commapi did. >> >> Another option may be the old kaffe extensions that moved to gnu >> classpathx. These don't have the native libraries but should provide >> the 2.0 interface and the javax.comm.properties mechansim for SPI. >> >> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From florianmanschwetus at gmx.de Tue Aug 5 05:04:46 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 13:04:46 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: References: <48971C1F.9020806@gmx.de> Message-ID: <489833CE.1040801@gmx.de> Just look at sendCommand in this method I have to place a Thread.sleep(20) after each byte send to get working. Even the event based receive doesn't work fine but this could be may stupidness. The specifikation document (it is on the last pages of the manual) for the beamer could be found on: http://www.optoma.co.uk/support.aspx Florian Manschwetus Trent Jarvi schrieb: > > Hi Florian > > Sorry for the top post in advance. I worry you may not see my answer > under all your code :) > > I have not received this email before. This is 500k of code which I > don't have time to read. I can spend about 5 min on each hobby email > and still get to work in the morning. I have a couple suggestions for > how to get an answer. > > First, cut out your comments and extra code so you can demonstrate the > question (I might even glance and see what is wrong then). Don't go for > a working final product. Isolate the problem using a simple program and > then ask with that as an example. If I did what you just did, I'd have > to post 3/4 of a million lines of code :) > > Second, join the rxtx mail-list and ask there. This will give you 100x > more eyes. I'll also read and try to follow. > > -- > taj > > > > On Mon, 4 Aug 2008, Florian Manschwetus wrote: > >> It could be that my university account is blocked by filters so >> resending from here. >> >> >> Topic is to control Optoma HD80 beamer using rs232 serial chat. >> This code is able to detect power state and switch the beamer on / off. >> connected is the beamer using a digitus usb 2.0 serial adapter with an >> FT232 USB-Serial adapter the systems architecture is amd64. >> >> Please take a look in the sendCommand routine i have to place theire >> those Thread.sleep to get it working. >> Now the question is this correct or is there a better way to get this >> working correctly? >> >> In the javadoc coming with the install i found this: >> setBaudBase >> >> public boolean setBaudBase(int BaudBase) >> throws UnsupportedCommOperationException, >> java.io.IOException >> >> Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 >> before using. >> >> could this explain the error? >> I attached my java source and the protocol description for the beamer >> (available on vendor website). >> >> thx, >> Florian Manschwetus >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: TestRS232.java Type: text/x-java Size: 9143 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0008.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0009.bin From michael.erskine at ketech.com Tue Aug 5 05:53:49 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Tue, 5 Aug 2008 12:53:49 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489833CE.1040801@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> > Just look at sendCommand in this method I have to place a > Thread.sleep(20) after each byte send to get working. Even the event > based receive doesn't work fine but this could be may stupidness. Hi Florian, Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. Regards, Michael Erskine. From florianmanschwetus at gmx.de Tue Aug 5 07:28:15 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:28:15 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> Message-ID: <4898556F.8000208@gmx.de> Michael Erskine schrieb: >> Just look at sendCommand in this method I have to place a >> Thread.sleep(20) after each byte send to get working. Even the event >> based receive doesn't work fine but this could be may stupidness. > > Hi Florian, > > Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. > > Regards, > Michael Erskine. > Ok, sounds fine for the receiving problem. But why i have to wait after each byte when sending a command squence? (the for loop in send command) Florian > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/284f350c/attachment-0003.bin From florianmanschwetus at gmx.de Tue Aug 5 07:44:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:44:14 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <4898592E.2020908@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >>> Just look at sendCommand in this method I have to place a >>> Thread.sleep(20) after each byte send to get working. Even the event >>> based receive doesn't work fine but this could be may stupidness. >> >> Hi Florian, >> >> Yes, naturally you'll have to wait for a response from the other end. >> Why not wait for notification from the event thread perhaps using a >> BlockingDeque rather than your LinkedList. Generally I >> try to decouple all input and output streams: in your case your >> application is operating synchronously like the "expect" program >> (http://expect.nist.gov/) so waits (or timeouts) will need to be >> factored in. >> >> Regards, >> Michael Erskine. >> > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) > > Florian Furthermore there is this basic baud with this confusing javadoc entry: public boolean setBaudBase(int BaudBase) throws UnsupportedCommOperationException, java.io.IOException Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 before using. maybe this could explain something Florian >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/006c7425/attachment-0003.bin From jredman at ergotech.com Tue Aug 5 09:13:36 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 05 Aug 2008 09:13:36 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: Message-ID: <48986E20.3060104@ergotech.com> Trent, So two issues: 1) Technically I'm still not sure how easy/practical a layer would be. The problems are always classes like listeners, and wrapping returns of gnu.io classes. I really see it as a "delegate" type of concept. Any thoughts or ideas of the practicality of this approach? The idea is not to modify RXTX. 2) Javax. The javax namespace does seem to be in widespread use outside of Sun (the same is true for the java namespace). The classpath extensions, or some other location, should be interested in a JavaComm implementation even if it does have dependencies on RXTX. Would you have any philosophical objection to an approach like that? Of course, I suspect it might be better if someone with that authority at Sun would admit that the javax namespace is already in the wild and that there is no problem with it being used within RXTX. Jim Trent Jarvi wrote: > Hi Jim, > > I will not step into the javax.comm namespace without Sun's explicite > permission. I fully understand the pain point you are trying to address. > > In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm > Linux) - which remains an integral part of rxtx. At the time it was a win for > Sun and rxtx. > > The Sun commapi license is/was fairly clear that rxtx should not step into that > namespace. It made sense as Sun was active in that space and rxtx may go into > another namespace - it was an experiment in working with Sun. > > This may sound silly looking at something that happened almost 10 years ago. > In a community of respect which Sun helped create, there is no question about > what to do. I hope eventually Sun will step up and do a right thing too. > > I agree that this is hurting the API more than helping it. There are also > questions about how to replace the API in the long term which includes HID > support which isn't going well so far. > > Others that can't even look at Sun's javax.comm today and can look at Kaffe's > contribution to classpathx can easily work around such restrictions. > > On Mon, 4 Aug 2008, Jim Redman wrote: > >> Has there been any work/would it be possible, to layer a javacomm >> look-alike on top of the GNU code? >> >> The goal is not to move the javax code forward, but to emulate the >> "legacy" javax packages for people who still need this. >> >> Jim >> >> Trent Jarvi wrote: >>> It would be nice to work with Sun to resolve those longstanding issues. >>> But it may not be practical unless the process goes as fast and painless >>> as the grandfathering of commapi did. >>> >>> Another option may be the old kaffe extensions that moved to gnu >>> classpathx. These don't have the native libraries but should provide >>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>> >>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From sandeep at genevasoftech.com Tue Aug 5 11:18:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Tue, 05 Aug 2008 22:48:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <48988B6C.5080409@genevasoftech.com> Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. *-- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/ad20f1cb/attachment-0003.html From Martin.Oberhuber at windriver.com Tue Aug 5 13:30:17 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Tue, 5 Aug 2008 21:30:17 +0200 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Sandeep, shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on Sol7 but I've successfully run it on Sol9 and Sol10. Or is your request really about a native 64bit variant? I'm afraid that then you're out of luck since I think that quite a bit of RXTX is not yet ready for 64 bit. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Sandeep Kumar K Sent: Tuesday, August 05, 2008 7:19 PM To: rxtx at qbang.org Subject: [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so for Solaris 9 Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. -- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/81b7f988/attachment-0003.html From tjarvi at qbang.org Tue Aug 5 22:38:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 22:38:34 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 5 Aug 2008, Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built > on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid that > then > you're out of luck since I think that quite a bit of RXTX is not yet > ready > for 64 bit. > While rxtx-2.1-7 probably has problems, The CVS code should be OK for 64 bit Solaris. If it isn't, let me know and I'll find which patch is missing. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Aug 5 23:13:00 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 23:13:00 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48986E20.3060104@ergotech.com> References: <48986E20.3060104@ergotech.com> Message-ID: On Tue, 5 Aug 2008, Jim Redman wrote: > Trent, > > So two issues: > > 1) Technically I'm still not sure how easy/practical a layer would be. The > problems are always classes like listeners, and wrapping returns of gnu.io > classes. I really see it as a "delegate" type of concept. Any thoughts or > ideas of the practicality of this approach? The idea is not to modify RXTX. I have not put too much thought into this. I assume you want what rxtx 2.0 provided to tie into javax.comm implementations. More classes could be added to rxtx 2.1-7 for SPI support. Maintaining rxtx-2.0 could also be handed to someone if they like. > > 2) Javax. The javax namespace does seem to be in widespread use outside of > Sun (the same is true for the java namespace). The classpath extensions, or > some other location, should be interested in a JavaComm implementation even > if it does have dependencies on RXTX. Would you have any philosophical > objection to an approach like that? > No problems. Classpathx would be a possible place to do it. I'd suggest thinking twice about what this involves in practical terms. You would be wanting to revive the 2.0 API while Sun is at 3.0 and grandfathering the JSR. This undermines the main reason (established api) for using the javax.comm namespace and does not leave such a project in a good position. The only win I see here is maintaining support for applications that can't migrate namespaces. Not that that isn't important. At some point it is going to be less work to just edit the bytecode :) Such a javax.comm effort would also be signing up new projects that decided to use the work up for concerns they probably will not understand or expect. That probably isn't a good path to facilitate for new projects at this time. We will put a good faith effort to work well with others but keep in mind the project has limited bandwidth for such efforts. > Of course, I suspect it might be better if someone with that authority at Sun > would admit that the javax namespace is already in the wild and that there is > no problem with it being used within RXTX. > > Jim > > Trent Jarvi wrote: >> Hi Jim, >> >> I will not step into the javax.comm namespace without Sun's explicite >> permission. I fully understand the pain point you are trying to address. >> >> In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java >> Comm Linux) - which remains an integral part of rxtx. At the time it was a >> win for Sun and rxtx. >> >> The Sun commapi license is/was fairly clear that rxtx should not step into >> that namespace. It made sense as Sun was active in that space and rxtx may >> go into another namespace - it was an experiment in working with Sun. >> >> This may sound silly looking at something that happened almost 10 years >> ago. In a community of respect which Sun helped create, there is no >> question about what to do. I hope eventually Sun will step up and do a >> right thing too. >> >> I agree that this is hurting the API more than helping it. There are also >> questions about how to replace the API in the long term which includes HID >> support which isn't going well so far. >> >> Others that can't even look at Sun's javax.comm today and can look at >> Kaffe's contribution to classpathx can easily work around such >> restrictions. >> >> On Mon, 4 Aug 2008, Jim Redman wrote: >> >>> Has there been any work/would it be possible, to layer a javacomm >>> look-alike on top of the GNU code? >>> >>> The goal is not to move the javax code forward, but to emulate the >>> "legacy" javax packages for people who still need this. >>> >>> Jim >>> >>> Trent Jarvi wrote: >>>> It would be nice to work with Sun to resolve those longstanding issues. >>>> But it may not be practical unless the process goes as fast and painless >>>> as the grandfathering of commapi did. >>>> >>>> Another option may be the old kaffe extensions that moved to gnu >>>> classpathx. These don't have the native libraries but should provide >>>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>>> >>>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From sandeep at genevasoftech.com Wed Aug 6 00:03:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Wed, 06 Aug 2008 11:33:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: <48993EB8.30107@genevasoftech.com> Thank you Mr. Martin for your suggestion. The native file which is given in rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am getting the following error . Any suggestions to solve this issue. I am using Solaris SPARC 64 bit machine. ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) thrown while loading gnu.io.RXTXCommDriver Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(Unknown Source) at java.lang.ClassLoader.loadLibrary(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) at com.ReadFromModem.main(ReadFromModem.java:84) * * *Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid > that then > you're out of luck since I think that quite a bit of RXTX is not yet ready > for 64 bit. > > Cheers, > -- > *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > ------------------------------------------------------------------------ > *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On > Behalf Of *Sandeep Kumar K > *Sent:* Tuesday, August 05, 2008 7:19 PM > *To:* rxtx at qbang.org > *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so > for Solaris 9 > > Hi, > > Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 > bit machine. The librxtxSerial.so given in website is for Solaris 8. > > *-- > > Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/1e920343/attachment-0003.html From tjarvi at qbang.org Wed Aug 6 00:21:42 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 00:21:42 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <48993EB8.30107@genevasoftech.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> <48993EB8.30107@genevasoftech.com> Message-ID: Hi Sandeep You may be out of luck unless you can compile the 2.1 src in CVS (requires gnu make and gcc). But you could try the ToyBox(R)(TM) which is a collection of WiLdLy untested cross compiled 2.1-7 binaries covering everything from the ibm z series to embeded arm/ppc. To give an idea how poorly these are tested, I don't even know if z series machines have a serial port. ftp://www.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Solaris They should at least match the binary types. Actually, I think if you use the rxtx jar from CVS with that file, it should 'work' as the fix for 64 bits was in java not the native code. You could just cd rxtx*/src; javac *.java then jar -cf RXTXcomm.jar `find -name \*.class` to create the hybrid which will complain about version information a bit. On Wed, 6 Aug 2008, Sandeep Kumar K wrote: > Thank you Mr. Martin for your suggestion. The native file which is given in > rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am > getting the following error . > Any suggestions to solve this issue. > I am using Solaris SPARC 64 bit machine. > > ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar > java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 > (Possible cause: architecture word > width mismatch) thrown while loading gnu.io.RXTXCommDriver > Exception in thread "main" java.lang.UnsatisfiedLinkError: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF > class: ELFCLASS64 (Possible cause: > architecture word width mismatch) > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(Unknown Source) > at java.lang.ClassLoader.loadLibrary(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > at com.ReadFromModem.main(ReadFromModem.java:84) > > * > * > > *Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > > > Oberhuber, Martin wrote: >> Sandeep, >> shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse >> variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on >> Sol7 but I've successfully run it on Sol9 and Sol10. >> Or is your request really about a native 64bit variant? I'm afraid that >> then >> you're out of luck since I think that quite a bit of RXTX is not yet ready >> for 64 bit. >> Cheers, >> -- >> *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> ------------------------------------------------------------------------ >> *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On >> Behalf Of *Sandeep Kumar K >> *Sent:* Tuesday, August 05, 2008 7:19 PM >> *To:* rxtx at qbang.org >> *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so >> for Solaris 9 >> >> Hi, >> >> Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 >> bit machine. The librxtxSerial.so given in website is for Solaris 8. >> >> *-- >> Thanks & Regards >> >> Sandeep Kumar K >> Sr. Software Engineer >> Geneva Software Technologies >> Whitefield, Bangalore >> Mob : 9880193454* >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> From michael.erskine at ketech.com Wed Aug 6 01:39:28 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 6 Aug 2008 08:39:28 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Florian Manschwetus wrote: > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) Hi Florian, I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. Regards, Michael Erskine. From florianmanschwetus at gmx.de Wed Aug 6 02:53:16 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 06 Aug 2008 10:53:16 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Message-ID: <4899667C.6010706@gmx.de> Michael Erskine schrieb: > Florian Manschwetus wrote: >> Ok, sounds fine for the receiving problem. >> But why i have to wait after each byte when sending a command squence? >> (the for loop in send command) > > Hi Florian, > I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. > > Regards, > Michael Erskine. > correct with a terminal on the other end it works, my idea was that this basic baud has some influence. Could some one explain what it is for? Florian > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/c2b4fa84/attachment-0003.bin From rick_knight at rlknight.com Wed Aug 6 13:01:07 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:01:07 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F4F3.3020707@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > I have an application (Readerware) that uses RXTX with Javax to access the serial port. This used to work fine under previous Linux' and Java, but something has changed, I assume with Java itself , that is causing the application to fail with a link error. The application is not able to find librxtxSerialParallel.so. RXTX supplies librxtxSerial.so and librxtxParallel.so, but not librxtxSerialParallel.so. Where can I get librxtxSerialParallel.so, or do I need it? Is something else causing the lib to not be found? Thanks, Rick Knight From rick_knight at rlknight.com Wed Aug 6 13:17:55 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:17:55 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F8E3.5060400@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Thanks for the reply. The developer of the app I'm trying to use (Readerware) has sent me a copy of the comm.api and I've copied the library (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar into the proper places. When I try to run the application, I get this error... Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: /usr/lib/libSolarisSerialParallel.so: /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not little-endian (Possible cause: endianness mismatch) Caught java.lang.UnsatisfiedLinkError: com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I while loading driver com.sun.comm.SolarisDriver Is there a way around this error? Thanks again, Rick Knight From jlar310 at gmail.com Wed Aug 6 13:37:42 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 14:37:42 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899F8E3.5060400@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > The developer of the app I'm trying to use (Readerware) has sent me a > copy of the comm.api and I've copied the library > (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar > into the proper places. When I try to run the application, I get this > error... > > Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: > /usr/lib/libSolarisSerialParallel.so: > /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not > little-endian (Possible cause: endianness mismatch) > Caught java.lang.UnsatisfiedLinkError: > com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I > > while loading driver com.sun.comm.SolarisDriver > > Is there a way around this error? What host OS are you running? From your original post it looks like 32 bit Linux. The libSolarisSerialParallel.so file is for Sun Solaris and will vary depending on the underlying hardware architecture as well. Sorry for the double post Rick, but I failed to send this to the list the first time... -- Jeff From rick_knight at rlknight.com Wed Aug 6 13:44:29 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:44:29 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: <4899FF1D.9030504@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > > >> The developer of the app I'm trying to use (Readerware) has sent me a >> copy of the comm.api and I've copied the library >> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >> into the proper places. When I try to run the application, I get this >> error... >> >> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >> /usr/lib/libSolarisSerialParallel.so: >> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >> little-endian (Possible cause: endianness mismatch) >> Caught java.lang.UnsatisfiedLinkError: >> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >> >> while loading driver com.sun.comm.SolarisDriver >> >> Is there a way around this error? >> > > What host OS are you running? From your original post it looks like 32 > bit Linux. > > The libSolarisSerialParallel.so file is for Sun Solaris and will vary > depending on the underlying hardware architecture as well. > > I'm running Kubuntu Linux (debian based). It's 32 bit. Rick Knight From jlar310 at gmail.com Wed Aug 6 15:33:23 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 16:33:23 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > I don't think Sun did binary libraries for Linux in the 2.0 version. Can someone with more historical experience than I confirm that? I recently tried to port a Comm API application from Solaris sparc to Linux x86 and likewise could not get my hands on the binary libraries. I eventually just re-wrote the code to use the gnu namespace packages and rxtx 2.1. What I don't understand is why your application vendor does not provide everything you need to run their software. FYI: I have librxtxParallel.so and librxtxSerial.so installed at JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is /usr/java/default which is actually a softlink to /usr/java/jre1.6.0_05. -- Jeff From defiantlew at yahoo.com.au Wed Aug 6 16:29:33 2008 From: defiantlew at yahoo.com.au (Lew L) Date: Thu, 7 Aug 2008 08:29:33 +1000 Subject: [Rxtx] Sun's Comm API Documentation References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> Message-ID: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> As a matter of interest is the Sun Comm API documentation available somewhere? I have tried the Sun site but it seems to have been removed. Unless I have missed the documentation for RXTX? I javadocced the RXTX source but information (to me) is minimal. Somewhere I got the impression that the Sun Comm API docs is, or was, compatible with RXTX, what is the best docs to use in conjuntion with RXTX and where may the be available? Cheers Lew From rick_knight at rlknight.com Wed Aug 6 17:18:33 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:18:33 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A3149.4050306@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff I'm not sure if I posted this here or not, but when I try to build RXTX from source I get this install error... make all-am make[1]: Entering directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' make[1]: Nothing to be done for `all-am'. make[1]: Leaving directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 Can you tell me how to get past this error and get RXTX built and installed? Thanks, Rick From bboyes at systronix.com Wed Aug 6 17:40:12 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Wed, 06 Aug 2008 17:40:12 -0600 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: At 16:29 08/06/2008, Lew L wrote: >As a matter of interest is the Sun Comm API documentation available >somewhere? I have tried the Sun site but it seems to have been removed. It's in the file we have posted, link in prev email (sorry, in a huge hurry right now). Javadocs definitely there. >Unless I have missed the documentation for RXTX? I javadocced the RXTX >source but information (to me) is minimal. >Somewhere I got the impression that the Sun Comm API docs is, or was, >compatible with RXTX, what is the best docs to use in conjuntion with RXTX >and where may the be available? Yeah, this is one of my concerns/beefs. There is little documentation for RXTX and it isn't just the same as javaxcomm. I would be willing to help out writing docs for RXTX! Yes really... esp if we can fix the Bluetooth issues. best regards Bruce >Cheers >Lew > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx ------- WWW.SYSTRONIX.COM ---------- Real embedded Java and much more +1-801-534-1017 Salt Lake City, USA From rick_knight at rlknight.com Wed Aug 6 17:54:08 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:54:08 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A39A0.2090309@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff, I would like for my vendor to switch to rxtx 2.1. It would make things much easier for me. I'm not sure why he's still using the javax compatible code. He's a small operation. Re-writing the code to use gnu namespace sounds like a major overhaul. Was it? Thanks, Rick From tjarvi at qbang.org Wed Aug 6 21:35:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:35:12 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: >> >>> Jeff wrote: >>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>>> >>>> >>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things > much easier for me. I'm not sure why he's still using the javax > compatible code. He's a small operation. Re-writing the code to use gnu > namespace sounds like a major overhaul. Was it? > Hi Jeff, The changes are fairly mechanical. Imports need to change and any explicite use of the namespace needs to change such as catching an exception. The following script was made for maintaining rxtx 2.0 but can apply to other needs. It is in the contrib dir with rxtx source. #!/bin/sh # Don't use! :) # # Sat, 03 May 2003 16:45:08 Modifications from J?rg Weule # Create a ed-cmd for the change of one pattern # case $1 in gnu) X=g/javax_comm/s+javax_comm+gnu_io+g ;; javax) X=g/gnu_io/s+gnu_io+javax_comm+g ;; *) echo;echo;echo From the top rxtx directory run;echo;echo -e \\t./ChangePackage.sh gnu;echo -e \\t\\tor;echo -e \\t./ChangePackage.sh javax;echo;echo; exit 0 ;; esac # # ed will be used to keep the owner and mode of the files unchanged. # We have run the ed-script for the characters '.' '/' as well. # "tr _ $D" do the change. # find . -type f -a -print | grep -v $0 | (while read F ; do ( echo $X; echo $X| tr _ /; echo $X| tr _ .; echo w; echo q ) | ed $F 2>&1 >/dev/null done ) # # Now we do little changes at the Makefiles. Hope that all we need. # find . -name Makefile\* -a -print | (while read F ; do cat < References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: On Thu, 7 Aug 2008, Lew L wrote: > As a matter of interest is the Sun Comm API documentation available > somewhere? I have tried the Sun site but it seems to have been removed. > > Unless I have missed the documentation for RXTX? I javadocced the RXTX > source but information (to me) is minimal. > Somewhere I got the impression that the Sun Comm API docs is, or was, > compatible with RXTX, what is the best docs to use in conjuntion with RXTX > and where may the be available? > Hi Lew, The documentation on Sun's website is accurate. The changes that are problematic in 3.0 are on the backside which rxtx used to plug into. http://java.sun.com/products/javacomm/reference/api/index.html CommPortIdentifier may have some minor differences (judging by the authors notes). -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Aug 6 21:46:08 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:46:08 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > If javax.comm.properties is properly installed and you are using a 2.0 version of Sun's commapi with rxtx 2.0, you should not see the library attempt to load libSolarisSerialParallel.so. Sun CommAPI 3.0 will not work with any version of rxtx as it is hard coded to use the shared library. See the INSTALL file with rxtx-2.0 source for more help with the properties file. -- Trent Jarvi tjarvi at qbang.org From jlar310 at gmail.com Thu Aug 7 06:32:06 2008 From: jlar310 at gmail.com (Jeff) Date: Thu, 7 Aug 2008 07:32:06 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > Jeff wrote: >> >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >> wrote: >> >>> >>> Jeff wrote: >>> >>>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>> wrote: >>>> >>>> >>>> >>>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things much > easier for me. I'm not sure why he's still using the javax compatible code. > He's a small operation. Re-writing the code to use gnu namespace sounds like > a major overhaul. Was it? I found it quite easy. In fact, in order to accommodate the transition, I actually separated all of the code that deals directly with the Comm API or RXTX into a helper class. The helper class was then coded to use reflection to determine which library was available and then instantiate the necessary objects. No direct imports of either library are used. The main application just needs to get it's hands on the IO streams and need not deal directly with the libraries. Other programs may not be so simple... But this doesn't really help you unless your vendor forks over the source code... -- Jeff From rick_knight at rlknight.com Thu Aug 7 09:47:12 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Thu, 07 Aug 2008 08:47:12 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: <489B1900.10108@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >>> wrote: >>> >>> >>>> Jeff wrote: >>>> >>>> >>>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>>> copy of the comm.api and I've copied the library >>>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>>> into the proper places. When I try to run the application, I get this >>>>>> error... >>>>>> >>>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>>> /usr/lib/libSolarisSerialParallel.so: >>>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>>> little-endian (Possible cause: endianness mismatch) >>>>>> Caught java.lang.UnsatisfiedLinkError: >>>>>> >>>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>>> >>>>>> while loading driver com.sun.comm.SolarisDriver >>>>>> >>>>>> Is there a way around this error? >>>>>> >>>>>> >>>>>> >>>>> What host OS are you running? From your original post it looks like 32 >>>>> bit Linux. >>>>> >>>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>>> depending on the underlying hardware architecture as well. >>>>> >>>>> >>>>> >>>>> >>>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>>> >>>> >>>> >>> I don't think Sun did binary libraries for Linux in the 2.0 version. >>> Can someone with more historical experience than I confirm that? >>> >>> I recently tried to port a Comm API application from Solaris sparc to >>> Linux x86 and likewise could not get my hands on the binary libraries. >>> I eventually just re-wrote the code to use the gnu namespace packages >>> and rxtx 2.1. >>> >>> What I don't understand is why your application vendor does not >>> provide everything you need to run their software. >>> >>> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >>> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >>> /usr/java/default which is actually a softlink to >>> /usr/java/jre1.6.0_05. >>> >>> >>> >> Jeff, >> >> I would like for my vendor to switch to rxtx 2.1. It would make things much >> easier for me. I'm not sure why he's still using the javax compatible code. >> He's a small operation. Re-writing the code to use gnu namespace sounds like >> a major overhaul. Was it? >> > > I found it quite easy. In fact, in order to accommodate the > transition, I actually separated all of the code that deals directly > with the Comm API or RXTX into a helper class. The helper class was > then coded to use reflection to determine which library was available > and then instantiate the necessary objects. No direct imports of > either library are used. The main application just needs to get it's > hands on the IO streams and need not deal directly with the libraries. > Other programs may not be so simple... > > But this doesn't really help you unless your vendor forks over the > source code... > > Jeff, This may not help me directly, but I'm going to forward this thread to the vendor. I think he'll be open to making things work. Thanks again, Rick Knight From agusmunioz at gmail.com Thu Aug 7 16:39:51 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Thu, 7 Aug 2008 19:39:51 -0300 Subject: [Rxtx] How to send ack? Message-ID: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Hi, I'm still learning about serial communication and I have some doubts. I've got this question about how to do the following thing in rxtx. I have this hardware that connect to a PC using a serial port. These hardware receives data from a telephone line, proccess it, and then send it forward to the serial port. I've used a program named wincomm that shows what information is send it through the serial port and I have the nex behaviour: The hardware has a buffer where all data is stored, that cannot be sent it through the seria port. The program reads the first data send it by the hardware, and keep reading the same data always. There is a button in the application that says enable Ack, and when I click, then the hardware start to send all the stored information, and all the information is shown. I write a class, using rxtx that reads the serial port, and the same thing happens, it remains reading the same (first) data all the time. And I thing something like the enable Ack I'm missing. How can I do this enable Ack from my java code using rxtx? Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080807/e0a0f9a1/attachment.html From ajmas at sympatico.ca Thu Aug 7 18:26:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 7 Aug 2008 20:26:41 -0400 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: <4BF42297-81E2-4BB8-A89F-1D43588379AE@sympatico.ca> On 6-Aug-08, at 19:40 , Bruce Boyes wrote: >> Unless I have missed the documentation for RXTX? I javadocced the >> RXTX >> source but information (to me) is minimal. >> Somewhere I got the impression that the Sun Comm API docs is, or was, >> compatible with RXTX, what is the best docs to use in conjuntion >> with RXTX >> and where may the be available? > > Yeah, this is one of my concerns/beefs. There is little documentation > for RXTX and it isn't just the same as javaxcomm. > > I would be willing to help out writing docs for RXTX! Yes really... > esp if we can fix the Bluetooth issues. If you want to contribute documentation then the best place to do that is the wiki. If there is anything missing or that could be improved on then please do so. If there are any points that you would like to see improved, for which you don't have the knowledge then ask on the mailing list for a volunteer. Andre From florianmanschwetus at gmx.de Fri Aug 8 03:04:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Fri, 08 Aug 2008 11:04:14 +0200 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Message-ID: <489C0C0E.2020401@gmx.de> Agustin Mu?oz schrieb: > Hi, I'm still learning about serial communication and I have some > doubts. I've got this question about how to do the following thing in rxtx. > I have this hardware that connect to a PC using a serial port. These > hardware receives data from a telephone line, proccess it, and then send > it forward to the serial port. I've used a program named wincomm that > shows what information is send it through the serial port and I have the > nex behaviour: > > The hardware has a buffer where all data is stored, that cannot be sent > it through the seria port. > The program reads the first data send it by the hardware, and keep > reading the same data always. > There is a button in the application that says enable Ack, and when I > click, then the hardware start to send all the stored information, and > all the information is shown. > > I write a class, using rxtx that reads the serial port, and the same > thing happens, it remains reading the same (first) data all the time. > And I thing something like the enable Ack I'm missing. > How can I do this enable Ack from my java code using rxtx? Afaik, a look at man ascii reveals: Okt Dez Hex Char 006 6 06 ACK So, i hope this will do the job: send(6); florian > > Thanks in advance > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/5b4965f8/attachment.bin From rick_knight at rlknight.com Mon Aug 4 13:25:10 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Mon, 04 Aug 2008 12:25:10 -0700 Subject: [Rxtx] Sun's Comm API? Message-ID: <48975796.4010600@rlknight.com> I have an application that requires the javax compatible version of RXTX and Sun's comm api. I've been able to download and extract the version of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api anywhere. Can someone tell me where I can find it? Or maybe send me a copy? Also, when I try to build RXTX, configure and make complete successfully but make install failes with this error libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 I've never come accross this error before. How can I get past it? Thanks, Rick From bboyes at systronix.com Mon Aug 4 19:10:01 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:10:01 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48975796.4010600@rlknight.com> References: <48975796.4010600@rlknight.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/cb9c6167/attachment-0005.html From bboyes at systronix.com Mon Aug 4 19:12:37 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:12:37 -0600 Subject: [Rxtx] Towards an RXTX release - CSR BT/USB chipset In-Reply-To: <488FB7E7.8000802@gmail.com> References: <460801A4097E3D4CA04CC64EE648584806C56CF0@ism-mail03.corp.ad.wrs.com> <13557-75390@sneakemail.com> <20980-23424@sneakemail.com> <488FB7E7.8000802@gmail.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/52236088/attachment-0005.html From tjarvi at qbang.org Mon Aug 4 19:42:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 19:42:21 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: On Mon, 4 Aug 2008, Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: > I have an application that requires the javax compatible > version of RXTX > and Sun's comm api. I've been able to download and extract > the version > of RXTX that I need (2.0-7pre2) but I can't find Sun's camm > api > anywhere. Can someone tell me where I can find it? Or maybe > send me a > > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm port > support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have just > a ZIP with only the .class JAR file - no source or docs), has a readme > with these comments: > > This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release.? The 2.0.3 release itself is > no longer distributed.? comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project.? The RxTx project (http://www.rxtx.org ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org) was opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support.? Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins.? Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > ? > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > I hope that is helpful! > It would be nice to work with Sun to resolve those longstanding issues. But it may not be practical unless the process goes as fast and painless as the grandfathering of commapi did. Another option may be the old kaffe extensions that moved to gnu classpathx. These don't have the native libraries but should provide the 2.0 interface and the javax.comm.properties mechansim for SPI. http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Mon Aug 4 20:23:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Mon, 04 Aug 2008 20:23:57 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4897B9BD.5070809@ergotech.com> Has there been any work/would it be possible, to layer a javacomm look-alike on top of the GNU code? The goal is not to move the javax code forward, but to emulate the "legacy" javax packages for people who still need this. Jim Trent Jarvi wrote: > On Mon, 4 Aug 2008, Bruce Boyes wrote: > >> At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible >> version of RXTX >> and Sun's comm api. I've been able to download and extract >> the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm >> api >> anywhere. Can someone tell me where I can find it? Or maybe >> send me a >> >> >> javaxcomm has had a sort of on-again off-again history. The windoze >> version has been languishing for years (literally) but there are newer >> versions for other OS's. >> >> We try to keep links on one of our help pages current: >> http://www.practicalembeddedjava.com/tools/javatools_list.html >> which gets you to here: >> http://java.sun.com/products/javacomm/ >> where it says in fact they no longer even support Windows and Mac: >> "Implementations of the API are currently available for Solaris SPARC, >> Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so >> someone could support it. But I guess that's part of the reason RXTX >> exists! >> >> So one of Sun's own products, SunSPOT, has to use RXTX to get comm port >> support. >> >> The version we use is 2.0 from 11/15/1998. I have posted it on our >> website, which is within the terms of the license agreement contained >> therein (as I understand it). >> >> The last version of javaxcomm for Windows, 2.0.3, (for which I have just >> a ZIP with only the .class JAR file - no source or docs), has a readme >> with these comments: >> >> This distribution contains the comm.jar file original part >> of the COMMAPI 2.0.3 release. The 2.0.3 release itself is >> no longer distributed. comm.jar, which contains the comm >> API java class files (eg. Sun's binary implementation of the >> interface classes), is being made available, unsupported, >> with no obligation to fix bugs, at the request of the RXTX >> project. The RxTx project (http://www.rxtx.org ), uses the >> comm.jar class files, but provides their own native library >> components to provide support for other platforms. >> >> The 2.0.3 comm.jar is being provided in this way because >> as of COMMAPI 3.x, the java binary implementation forked and >> became incompatible with the RxTx project's native code. >> Due to the lack of a clear business case, and to resource >> constraints, no additional resources are being >> provided to provide an alternative engineering solution >> at the time of writing. >> >> RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: >> >> Ultimately the COMMAPI would be better served if a Java >> Community Process JSR (http://www.jcp.org) was opened and >> the COMMAPI was rearchitected to provide a more pluggable >> framework to improve cross-platform support. Such an >> architecture would embody a better defined and better >> documented SPI interface, including a way for comm. ports >> to be revealed to the client application through the API >> via platform-aware plugins. Similarly, native code used >> to access comm port in general could be handled more >> flexibly using a plugin model, whereby on any platform, >> multiple native modules could be in use simultaneously. >> >> Since there are now various ways serial ports can be implemented >> and accessed, modular comm. port JNI native libraries would be >> of benefit insofar as removing the burden of over-generalization >> from any single native component, or inversely, by relieving the >> implicit constraint that comm. drivers be accessed only via a >> monolithic mechanism, such as the UNIX vnode interface. >> >> paul.klissner at sun.com >> 6/10/06 >> >> I hope that is helpful! >> > > It would be nice to work with Sun to resolve those longstanding issues. > But it may not be practical unless the process goes as fast and painless > as the grandfathering of commapi did. > > Another option may be the old kaffe extensions that moved to gnu > classpathx. These don't have the native libraries but should provide > the 2.0 interface and the javax.comm.properties mechansim for SPI. > > http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Mon Aug 4 21:09:15 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 21:09:15 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? Message-ID: Hi Jim, I will not step into the javax.comm namespace without Sun's explicite permission. I fully understand the pain point you are trying to address. In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm Linux) - which remains an integral part of rxtx. At the time it was a win for Sun and rxtx. The Sun commapi license is/was fairly clear that rxtx should not step into that namespace. It made sense as Sun was active in that space and rxtx may go into another namespace - it was an experiment in working with Sun. This may sound silly looking at something that happened almost 10 years ago. In a community of respect which Sun helped create, there is no question about what to do. I hope eventually Sun will step up and do a right thing too. I agree that this is hurting the API more than helping it. There are also questions about how to replace the API in the long term which includes HID support which isn't going well so far. Others that can't even look at Sun's javax.comm today and can look at Kaffe's contribution to classpathx can easily work around such restrictions. On Mon, 4 Aug 2008, Jim Redman wrote: > Has there been any work/would it be possible, to layer a javacomm > look-alike on top of the GNU code? > > The goal is not to move the javax code forward, but to emulate the > "legacy" javax packages for people who still need this. > > Jim > > Trent Jarvi wrote: >> >> It would be nice to work with Sun to resolve those longstanding issues. >> But it may not be practical unless the process goes as fast and painless >> as the grandfathering of commapi did. >> >> Another option may be the old kaffe extensions that moved to gnu >> classpathx. These don't have the native libraries but should provide >> the 2.0 interface and the javax.comm.properties mechansim for SPI. >> >> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From florianmanschwetus at gmx.de Tue Aug 5 05:04:46 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 13:04:46 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: References: <48971C1F.9020806@gmx.de> Message-ID: <489833CE.1040801@gmx.de> Just look at sendCommand in this method I have to place a Thread.sleep(20) after each byte send to get working. Even the event based receive doesn't work fine but this could be may stupidness. The specifikation document (it is on the last pages of the manual) for the beamer could be found on: http://www.optoma.co.uk/support.aspx Florian Manschwetus Trent Jarvi schrieb: > > Hi Florian > > Sorry for the top post in advance. I worry you may not see my answer > under all your code :) > > I have not received this email before. This is 500k of code which I > don't have time to read. I can spend about 5 min on each hobby email > and still get to work in the morning. I have a couple suggestions for > how to get an answer. > > First, cut out your comments and extra code so you can demonstrate the > question (I might even glance and see what is wrong then). Don't go for > a working final product. Isolate the problem using a simple program and > then ask with that as an example. If I did what you just did, I'd have > to post 3/4 of a million lines of code :) > > Second, join the rxtx mail-list and ask there. This will give you 100x > more eyes. I'll also read and try to follow. > > -- > taj > > > > On Mon, 4 Aug 2008, Florian Manschwetus wrote: > >> It could be that my university account is blocked by filters so >> resending from here. >> >> >> Topic is to control Optoma HD80 beamer using rs232 serial chat. >> This code is able to detect power state and switch the beamer on / off. >> connected is the beamer using a digitus usb 2.0 serial adapter with an >> FT232 USB-Serial adapter the systems architecture is amd64. >> >> Please take a look in the sendCommand routine i have to place theire >> those Thread.sleep to get it working. >> Now the question is this correct or is there a better way to get this >> working correctly? >> >> In the javadoc coming with the install i found this: >> setBaudBase >> >> public boolean setBaudBase(int BaudBase) >> throws UnsupportedCommOperationException, >> java.io.IOException >> >> Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 >> before using. >> >> could this explain the error? >> I attached my java source and the protocol description for the beamer >> (available on vendor website). >> >> thx, >> Florian Manschwetus >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: TestRS232.java Type: text/x-java Size: 9143 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0010.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0011.bin From michael.erskine at ketech.com Tue Aug 5 05:53:49 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Tue, 5 Aug 2008 12:53:49 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489833CE.1040801@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> > Just look at sendCommand in this method I have to place a > Thread.sleep(20) after each byte send to get working. Even the event > based receive doesn't work fine but this could be may stupidness. Hi Florian, Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. Regards, Michael Erskine. From florianmanschwetus at gmx.de Tue Aug 5 07:28:15 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:28:15 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> Message-ID: <4898556F.8000208@gmx.de> Michael Erskine schrieb: >> Just look at sendCommand in this method I have to place a >> Thread.sleep(20) after each byte send to get working. Even the event >> based receive doesn't work fine but this could be may stupidness. > > Hi Florian, > > Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. > > Regards, > Michael Erskine. > Ok, sounds fine for the receiving problem. But why i have to wait after each byte when sending a command squence? (the for loop in send command) Florian > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/284f350c/attachment-0004.bin From florianmanschwetus at gmx.de Tue Aug 5 07:44:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:44:14 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <4898592E.2020908@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >>> Just look at sendCommand in this method I have to place a >>> Thread.sleep(20) after each byte send to get working. Even the event >>> based receive doesn't work fine but this could be may stupidness. >> >> Hi Florian, >> >> Yes, naturally you'll have to wait for a response from the other end. >> Why not wait for notification from the event thread perhaps using a >> BlockingDeque rather than your LinkedList. Generally I >> try to decouple all input and output streams: in your case your >> application is operating synchronously like the "expect" program >> (http://expect.nist.gov/) so waits (or timeouts) will need to be >> factored in. >> >> Regards, >> Michael Erskine. >> > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) > > Florian Furthermore there is this basic baud with this confusing javadoc entry: public boolean setBaudBase(int BaudBase) throws UnsupportedCommOperationException, java.io.IOException Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 before using. maybe this could explain something Florian >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/006c7425/attachment-0004.bin From jredman at ergotech.com Tue Aug 5 09:13:36 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 05 Aug 2008 09:13:36 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: Message-ID: <48986E20.3060104@ergotech.com> Trent, So two issues: 1) Technically I'm still not sure how easy/practical a layer would be. The problems are always classes like listeners, and wrapping returns of gnu.io classes. I really see it as a "delegate" type of concept. Any thoughts or ideas of the practicality of this approach? The idea is not to modify RXTX. 2) Javax. The javax namespace does seem to be in widespread use outside of Sun (the same is true for the java namespace). The classpath extensions, or some other location, should be interested in a JavaComm implementation even if it does have dependencies on RXTX. Would you have any philosophical objection to an approach like that? Of course, I suspect it might be better if someone with that authority at Sun would admit that the javax namespace is already in the wild and that there is no problem with it being used within RXTX. Jim Trent Jarvi wrote: > Hi Jim, > > I will not step into the javax.comm namespace without Sun's explicite > permission. I fully understand the pain point you are trying to address. > > In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm > Linux) - which remains an integral part of rxtx. At the time it was a win for > Sun and rxtx. > > The Sun commapi license is/was fairly clear that rxtx should not step into that > namespace. It made sense as Sun was active in that space and rxtx may go into > another namespace - it was an experiment in working with Sun. > > This may sound silly looking at something that happened almost 10 years ago. > In a community of respect which Sun helped create, there is no question about > what to do. I hope eventually Sun will step up and do a right thing too. > > I agree that this is hurting the API more than helping it. There are also > questions about how to replace the API in the long term which includes HID > support which isn't going well so far. > > Others that can't even look at Sun's javax.comm today and can look at Kaffe's > contribution to classpathx can easily work around such restrictions. > > On Mon, 4 Aug 2008, Jim Redman wrote: > >> Has there been any work/would it be possible, to layer a javacomm >> look-alike on top of the GNU code? >> >> The goal is not to move the javax code forward, but to emulate the >> "legacy" javax packages for people who still need this. >> >> Jim >> >> Trent Jarvi wrote: >>> It would be nice to work with Sun to resolve those longstanding issues. >>> But it may not be practical unless the process goes as fast and painless >>> as the grandfathering of commapi did. >>> >>> Another option may be the old kaffe extensions that moved to gnu >>> classpathx. These don't have the native libraries but should provide >>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>> >>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From sandeep at genevasoftech.com Tue Aug 5 11:18:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Tue, 05 Aug 2008 22:48:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <48988B6C.5080409@genevasoftech.com> Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. *-- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/ad20f1cb/attachment-0004.html From Martin.Oberhuber at windriver.com Tue Aug 5 13:30:17 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Tue, 5 Aug 2008 21:30:17 +0200 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Sandeep, shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on Sol7 but I've successfully run it on Sol9 and Sol10. Or is your request really about a native 64bit variant? I'm afraid that then you're out of luck since I think that quite a bit of RXTX is not yet ready for 64 bit. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Sandeep Kumar K Sent: Tuesday, August 05, 2008 7:19 PM To: rxtx at qbang.org Subject: [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so for Solaris 9 Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. -- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/81b7f988/attachment-0004.html From tjarvi at qbang.org Tue Aug 5 22:38:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 22:38:34 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 5 Aug 2008, Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built > on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid that > then > you're out of luck since I think that quite a bit of RXTX is not yet > ready > for 64 bit. > While rxtx-2.1-7 probably has problems, The CVS code should be OK for 64 bit Solaris. If it isn't, let me know and I'll find which patch is missing. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Aug 5 23:13:00 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 23:13:00 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48986E20.3060104@ergotech.com> References: <48986E20.3060104@ergotech.com> Message-ID: On Tue, 5 Aug 2008, Jim Redman wrote: > Trent, > > So two issues: > > 1) Technically I'm still not sure how easy/practical a layer would be. The > problems are always classes like listeners, and wrapping returns of gnu.io > classes. I really see it as a "delegate" type of concept. Any thoughts or > ideas of the practicality of this approach? The idea is not to modify RXTX. I have not put too much thought into this. I assume you want what rxtx 2.0 provided to tie into javax.comm implementations. More classes could be added to rxtx 2.1-7 for SPI support. Maintaining rxtx-2.0 could also be handed to someone if they like. > > 2) Javax. The javax namespace does seem to be in widespread use outside of > Sun (the same is true for the java namespace). The classpath extensions, or > some other location, should be interested in a JavaComm implementation even > if it does have dependencies on RXTX. Would you have any philosophical > objection to an approach like that? > No problems. Classpathx would be a possible place to do it. I'd suggest thinking twice about what this involves in practical terms. You would be wanting to revive the 2.0 API while Sun is at 3.0 and grandfathering the JSR. This undermines the main reason (established api) for using the javax.comm namespace and does not leave such a project in a good position. The only win I see here is maintaining support for applications that can't migrate namespaces. Not that that isn't important. At some point it is going to be less work to just edit the bytecode :) Such a javax.comm effort would also be signing up new projects that decided to use the work up for concerns they probably will not understand or expect. That probably isn't a good path to facilitate for new projects at this time. We will put a good faith effort to work well with others but keep in mind the project has limited bandwidth for such efforts. > Of course, I suspect it might be better if someone with that authority at Sun > would admit that the javax namespace is already in the wild and that there is > no problem with it being used within RXTX. > > Jim > > Trent Jarvi wrote: >> Hi Jim, >> >> I will not step into the javax.comm namespace without Sun's explicite >> permission. I fully understand the pain point you are trying to address. >> >> In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java >> Comm Linux) - which remains an integral part of rxtx. At the time it was a >> win for Sun and rxtx. >> >> The Sun commapi license is/was fairly clear that rxtx should not step into >> that namespace. It made sense as Sun was active in that space and rxtx may >> go into another namespace - it was an experiment in working with Sun. >> >> This may sound silly looking at something that happened almost 10 years >> ago. In a community of respect which Sun helped create, there is no >> question about what to do. I hope eventually Sun will step up and do a >> right thing too. >> >> I agree that this is hurting the API more than helping it. There are also >> questions about how to replace the API in the long term which includes HID >> support which isn't going well so far. >> >> Others that can't even look at Sun's javax.comm today and can look at >> Kaffe's contribution to classpathx can easily work around such >> restrictions. >> >> On Mon, 4 Aug 2008, Jim Redman wrote: >> >>> Has there been any work/would it be possible, to layer a javacomm >>> look-alike on top of the GNU code? >>> >>> The goal is not to move the javax code forward, but to emulate the >>> "legacy" javax packages for people who still need this. >>> >>> Jim >>> >>> Trent Jarvi wrote: >>>> It would be nice to work with Sun to resolve those longstanding issues. >>>> But it may not be practical unless the process goes as fast and painless >>>> as the grandfathering of commapi did. >>>> >>>> Another option may be the old kaffe extensions that moved to gnu >>>> classpathx. These don't have the native libraries but should provide >>>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>>> >>>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From sandeep at genevasoftech.com Wed Aug 6 00:03:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Wed, 06 Aug 2008 11:33:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: <48993EB8.30107@genevasoftech.com> Thank you Mr. Martin for your suggestion. The native file which is given in rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am getting the following error . Any suggestions to solve this issue. I am using Solaris SPARC 64 bit machine. ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) thrown while loading gnu.io.RXTXCommDriver Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(Unknown Source) at java.lang.ClassLoader.loadLibrary(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) at com.ReadFromModem.main(ReadFromModem.java:84) * * *Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid > that then > you're out of luck since I think that quite a bit of RXTX is not yet ready > for 64 bit. > > Cheers, > -- > *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > ------------------------------------------------------------------------ > *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On > Behalf Of *Sandeep Kumar K > *Sent:* Tuesday, August 05, 2008 7:19 PM > *To:* rxtx at qbang.org > *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so > for Solaris 9 > > Hi, > > Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 > bit machine. The librxtxSerial.so given in website is for Solaris 8. > > *-- > > Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/1e920343/attachment-0004.html From tjarvi at qbang.org Wed Aug 6 00:21:42 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 00:21:42 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <48993EB8.30107@genevasoftech.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> <48993EB8.30107@genevasoftech.com> Message-ID: Hi Sandeep You may be out of luck unless you can compile the 2.1 src in CVS (requires gnu make and gcc). But you could try the ToyBox(R)(TM) which is a collection of WiLdLy untested cross compiled 2.1-7 binaries covering everything from the ibm z series to embeded arm/ppc. To give an idea how poorly these are tested, I don't even know if z series machines have a serial port. ftp://www.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Solaris They should at least match the binary types. Actually, I think if you use the rxtx jar from CVS with that file, it should 'work' as the fix for 64 bits was in java not the native code. You could just cd rxtx*/src; javac *.java then jar -cf RXTXcomm.jar `find -name \*.class` to create the hybrid which will complain about version information a bit. On Wed, 6 Aug 2008, Sandeep Kumar K wrote: > Thank you Mr. Martin for your suggestion. The native file which is given in > rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am > getting the following error . > Any suggestions to solve this issue. > I am using Solaris SPARC 64 bit machine. > > ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar > java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 > (Possible cause: architecture word > width mismatch) thrown while loading gnu.io.RXTXCommDriver > Exception in thread "main" java.lang.UnsatisfiedLinkError: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF > class: ELFCLASS64 (Possible cause: > architecture word width mismatch) > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(Unknown Source) > at java.lang.ClassLoader.loadLibrary(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > at com.ReadFromModem.main(ReadFromModem.java:84) > > * > * > > *Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > > > Oberhuber, Martin wrote: >> Sandeep, >> shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse >> variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on >> Sol7 but I've successfully run it on Sol9 and Sol10. >> Or is your request really about a native 64bit variant? I'm afraid that >> then >> you're out of luck since I think that quite a bit of RXTX is not yet ready >> for 64 bit. >> Cheers, >> -- >> *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> ------------------------------------------------------------------------ >> *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On >> Behalf Of *Sandeep Kumar K >> *Sent:* Tuesday, August 05, 2008 7:19 PM >> *To:* rxtx at qbang.org >> *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so >> for Solaris 9 >> >> Hi, >> >> Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 >> bit machine. The librxtxSerial.so given in website is for Solaris 8. >> >> *-- >> Thanks & Regards >> >> Sandeep Kumar K >> Sr. Software Engineer >> Geneva Software Technologies >> Whitefield, Bangalore >> Mob : 9880193454* >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> From michael.erskine at ketech.com Wed Aug 6 01:39:28 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 6 Aug 2008 08:39:28 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Florian Manschwetus wrote: > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) Hi Florian, I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. Regards, Michael Erskine. From florianmanschwetus at gmx.de Wed Aug 6 02:53:16 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 06 Aug 2008 10:53:16 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Message-ID: <4899667C.6010706@gmx.de> Michael Erskine schrieb: > Florian Manschwetus wrote: >> Ok, sounds fine for the receiving problem. >> But why i have to wait after each byte when sending a command squence? >> (the for loop in send command) > > Hi Florian, > I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. > > Regards, > Michael Erskine. > correct with a terminal on the other end it works, my idea was that this basic baud has some influence. Could some one explain what it is for? Florian > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/c2b4fa84/attachment-0004.bin From rick_knight at rlknight.com Wed Aug 6 13:01:07 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:01:07 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F4F3.3020707@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > I have an application (Readerware) that uses RXTX with Javax to access the serial port. This used to work fine under previous Linux' and Java, but something has changed, I assume with Java itself , that is causing the application to fail with a link error. The application is not able to find librxtxSerialParallel.so. RXTX supplies librxtxSerial.so and librxtxParallel.so, but not librxtxSerialParallel.so. Where can I get librxtxSerialParallel.so, or do I need it? Is something else causing the lib to not be found? Thanks, Rick Knight From rick_knight at rlknight.com Wed Aug 6 13:17:55 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:17:55 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F8E3.5060400@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Thanks for the reply. The developer of the app I'm trying to use (Readerware) has sent me a copy of the comm.api and I've copied the library (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar into the proper places. When I try to run the application, I get this error... Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: /usr/lib/libSolarisSerialParallel.so: /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not little-endian (Possible cause: endianness mismatch) Caught java.lang.UnsatisfiedLinkError: com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I while loading driver com.sun.comm.SolarisDriver Is there a way around this error? Thanks again, Rick Knight From jlar310 at gmail.com Wed Aug 6 13:37:42 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 14:37:42 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899F8E3.5060400@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > The developer of the app I'm trying to use (Readerware) has sent me a > copy of the comm.api and I've copied the library > (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar > into the proper places. When I try to run the application, I get this > error... > > Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: > /usr/lib/libSolarisSerialParallel.so: > /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not > little-endian (Possible cause: endianness mismatch) > Caught java.lang.UnsatisfiedLinkError: > com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I > > while loading driver com.sun.comm.SolarisDriver > > Is there a way around this error? What host OS are you running? From your original post it looks like 32 bit Linux. The libSolarisSerialParallel.so file is for Sun Solaris and will vary depending on the underlying hardware architecture as well. Sorry for the double post Rick, but I failed to send this to the list the first time... -- Jeff From rick_knight at rlknight.com Wed Aug 6 13:44:29 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:44:29 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: <4899FF1D.9030504@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > > >> The developer of the app I'm trying to use (Readerware) has sent me a >> copy of the comm.api and I've copied the library >> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >> into the proper places. When I try to run the application, I get this >> error... >> >> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >> /usr/lib/libSolarisSerialParallel.so: >> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >> little-endian (Possible cause: endianness mismatch) >> Caught java.lang.UnsatisfiedLinkError: >> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >> >> while loading driver com.sun.comm.SolarisDriver >> >> Is there a way around this error? >> > > What host OS are you running? From your original post it looks like 32 > bit Linux. > > The libSolarisSerialParallel.so file is for Sun Solaris and will vary > depending on the underlying hardware architecture as well. > > I'm running Kubuntu Linux (debian based). It's 32 bit. Rick Knight From jlar310 at gmail.com Wed Aug 6 15:33:23 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 16:33:23 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > I don't think Sun did binary libraries for Linux in the 2.0 version. Can someone with more historical experience than I confirm that? I recently tried to port a Comm API application from Solaris sparc to Linux x86 and likewise could not get my hands on the binary libraries. I eventually just re-wrote the code to use the gnu namespace packages and rxtx 2.1. What I don't understand is why your application vendor does not provide everything you need to run their software. FYI: I have librxtxParallel.so and librxtxSerial.so installed at JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is /usr/java/default which is actually a softlink to /usr/java/jre1.6.0_05. -- Jeff From defiantlew at yahoo.com.au Wed Aug 6 16:29:33 2008 From: defiantlew at yahoo.com.au (Lew L) Date: Thu, 7 Aug 2008 08:29:33 +1000 Subject: [Rxtx] Sun's Comm API Documentation References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> Message-ID: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> As a matter of interest is the Sun Comm API documentation available somewhere? I have tried the Sun site but it seems to have been removed. Unless I have missed the documentation for RXTX? I javadocced the RXTX source but information (to me) is minimal. Somewhere I got the impression that the Sun Comm API docs is, or was, compatible with RXTX, what is the best docs to use in conjuntion with RXTX and where may the be available? Cheers Lew From rick_knight at rlknight.com Wed Aug 6 17:18:33 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:18:33 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A3149.4050306@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff I'm not sure if I posted this here or not, but when I try to build RXTX from source I get this install error... make all-am make[1]: Entering directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' make[1]: Nothing to be done for `all-am'. make[1]: Leaving directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 Can you tell me how to get past this error and get RXTX built and installed? Thanks, Rick From bboyes at systronix.com Wed Aug 6 17:40:12 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Wed, 06 Aug 2008 17:40:12 -0600 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: At 16:29 08/06/2008, Lew L wrote: >As a matter of interest is the Sun Comm API documentation available >somewhere? I have tried the Sun site but it seems to have been removed. It's in the file we have posted, link in prev email (sorry, in a huge hurry right now). Javadocs definitely there. >Unless I have missed the documentation for RXTX? I javadocced the RXTX >source but information (to me) is minimal. >Somewhere I got the impression that the Sun Comm API docs is, or was, >compatible with RXTX, what is the best docs to use in conjuntion with RXTX >and where may the be available? Yeah, this is one of my concerns/beefs. There is little documentation for RXTX and it isn't just the same as javaxcomm. I would be willing to help out writing docs for RXTX! Yes really... esp if we can fix the Bluetooth issues. best regards Bruce >Cheers >Lew > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx ------- WWW.SYSTRONIX.COM ---------- Real embedded Java and much more +1-801-534-1017 Salt Lake City, USA From rick_knight at rlknight.com Wed Aug 6 17:54:08 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:54:08 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A39A0.2090309@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff, I would like for my vendor to switch to rxtx 2.1. It would make things much easier for me. I'm not sure why he's still using the javax compatible code. He's a small operation. Re-writing the code to use gnu namespace sounds like a major overhaul. Was it? Thanks, Rick From tjarvi at qbang.org Wed Aug 6 21:35:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:35:12 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: >> >>> Jeff wrote: >>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>>> >>>> >>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things > much easier for me. I'm not sure why he's still using the javax > compatible code. He's a small operation. Re-writing the code to use gnu > namespace sounds like a major overhaul. Was it? > Hi Jeff, The changes are fairly mechanical. Imports need to change and any explicite use of the namespace needs to change such as catching an exception. The following script was made for maintaining rxtx 2.0 but can apply to other needs. It is in the contrib dir with rxtx source. #!/bin/sh # Don't use! :) # # Sat, 03 May 2003 16:45:08 Modifications from J?rg Weule # Create a ed-cmd for the change of one pattern # case $1 in gnu) X=g/javax_comm/s+javax_comm+gnu_io+g ;; javax) X=g/gnu_io/s+gnu_io+javax_comm+g ;; *) echo;echo;echo From the top rxtx directory run;echo;echo -e \\t./ChangePackage.sh gnu;echo -e \\t\\tor;echo -e \\t./ChangePackage.sh javax;echo;echo; exit 0 ;; esac # # ed will be used to keep the owner and mode of the files unchanged. # We have run the ed-script for the characters '.' '/' as well. # "tr _ $D" do the change. # find . -type f -a -print | grep -v $0 | (while read F ; do ( echo $X; echo $X| tr _ /; echo $X| tr _ .; echo w; echo q ) | ed $F 2>&1 >/dev/null done ) # # Now we do little changes at the Makefiles. Hope that all we need. # find . -name Makefile\* -a -print | (while read F ; do cat < References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: On Thu, 7 Aug 2008, Lew L wrote: > As a matter of interest is the Sun Comm API documentation available > somewhere? I have tried the Sun site but it seems to have been removed. > > Unless I have missed the documentation for RXTX? I javadocced the RXTX > source but information (to me) is minimal. > Somewhere I got the impression that the Sun Comm API docs is, or was, > compatible with RXTX, what is the best docs to use in conjuntion with RXTX > and where may the be available? > Hi Lew, The documentation on Sun's website is accurate. The changes that are problematic in 3.0 are on the backside which rxtx used to plug into. http://java.sun.com/products/javacomm/reference/api/index.html CommPortIdentifier may have some minor differences (judging by the authors notes). -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Aug 6 21:46:08 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:46:08 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > If javax.comm.properties is properly installed and you are using a 2.0 version of Sun's commapi with rxtx 2.0, you should not see the library attempt to load libSolarisSerialParallel.so. Sun CommAPI 3.0 will not work with any version of rxtx as it is hard coded to use the shared library. See the INSTALL file with rxtx-2.0 source for more help with the properties file. -- Trent Jarvi tjarvi at qbang.org From jlar310 at gmail.com Thu Aug 7 06:32:06 2008 From: jlar310 at gmail.com (Jeff) Date: Thu, 7 Aug 2008 07:32:06 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > Jeff wrote: >> >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >> wrote: >> >>> >>> Jeff wrote: >>> >>>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>> wrote: >>>> >>>> >>>> >>>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things much > easier for me. I'm not sure why he's still using the javax compatible code. > He's a small operation. Re-writing the code to use gnu namespace sounds like > a major overhaul. Was it? I found it quite easy. In fact, in order to accommodate the transition, I actually separated all of the code that deals directly with the Comm API or RXTX into a helper class. The helper class was then coded to use reflection to determine which library was available and then instantiate the necessary objects. No direct imports of either library are used. The main application just needs to get it's hands on the IO streams and need not deal directly with the libraries. Other programs may not be so simple... But this doesn't really help you unless your vendor forks over the source code... -- Jeff From rick_knight at rlknight.com Thu Aug 7 09:47:12 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Thu, 07 Aug 2008 08:47:12 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: <489B1900.10108@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >>> wrote: >>> >>> >>>> Jeff wrote: >>>> >>>> >>>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>>> copy of the comm.api and I've copied the library >>>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>>> into the proper places. When I try to run the application, I get this >>>>>> error... >>>>>> >>>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>>> /usr/lib/libSolarisSerialParallel.so: >>>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>>> little-endian (Possible cause: endianness mismatch) >>>>>> Caught java.lang.UnsatisfiedLinkError: >>>>>> >>>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>>> >>>>>> while loading driver com.sun.comm.SolarisDriver >>>>>> >>>>>> Is there a way around this error? >>>>>> >>>>>> >>>>>> >>>>> What host OS are you running? From your original post it looks like 32 >>>>> bit Linux. >>>>> >>>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>>> depending on the underlying hardware architecture as well. >>>>> >>>>> >>>>> >>>>> >>>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>>> >>>> >>>> >>> I don't think Sun did binary libraries for Linux in the 2.0 version. >>> Can someone with more historical experience than I confirm that? >>> >>> I recently tried to port a Comm API application from Solaris sparc to >>> Linux x86 and likewise could not get my hands on the binary libraries. >>> I eventually just re-wrote the code to use the gnu namespace packages >>> and rxtx 2.1. >>> >>> What I don't understand is why your application vendor does not >>> provide everything you need to run their software. >>> >>> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >>> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >>> /usr/java/default which is actually a softlink to >>> /usr/java/jre1.6.0_05. >>> >>> >>> >> Jeff, >> >> I would like for my vendor to switch to rxtx 2.1. It would make things much >> easier for me. I'm not sure why he's still using the javax compatible code. >> He's a small operation. Re-writing the code to use gnu namespace sounds like >> a major overhaul. Was it? >> > > I found it quite easy. In fact, in order to accommodate the > transition, I actually separated all of the code that deals directly > with the Comm API or RXTX into a helper class. The helper class was > then coded to use reflection to determine which library was available > and then instantiate the necessary objects. No direct imports of > either library are used. The main application just needs to get it's > hands on the IO streams and need not deal directly with the libraries. > Other programs may not be so simple... > > But this doesn't really help you unless your vendor forks over the > source code... > > Jeff, This may not help me directly, but I'm going to forward this thread to the vendor. I think he'll be open to making things work. Thanks again, Rick Knight From agusmunioz at gmail.com Thu Aug 7 16:39:51 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Thu, 7 Aug 2008 19:39:51 -0300 Subject: [Rxtx] How to send ack? Message-ID: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Hi, I'm still learning about serial communication and I have some doubts. I've got this question about how to do the following thing in rxtx. I have this hardware that connect to a PC using a serial port. These hardware receives data from a telephone line, proccess it, and then send it forward to the serial port. I've used a program named wincomm that shows what information is send it through the serial port and I have the nex behaviour: The hardware has a buffer where all data is stored, that cannot be sent it through the seria port. The program reads the first data send it by the hardware, and keep reading the same data always. There is a button in the application that says enable Ack, and when I click, then the hardware start to send all the stored information, and all the information is shown. I write a class, using rxtx that reads the serial port, and the same thing happens, it remains reading the same (first) data all the time. And I thing something like the enable Ack I'm missing. How can I do this enable Ack from my java code using rxtx? Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080807/e0a0f9a1/attachment-0002.html From ajmas at sympatico.ca Thu Aug 7 18:26:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 7 Aug 2008 20:26:41 -0400 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: <4BF42297-81E2-4BB8-A89F-1D43588379AE@sympatico.ca> On 6-Aug-08, at 19:40 , Bruce Boyes wrote: >> Unless I have missed the documentation for RXTX? I javadocced the >> RXTX >> source but information (to me) is minimal. >> Somewhere I got the impression that the Sun Comm API docs is, or was, >> compatible with RXTX, what is the best docs to use in conjuntion >> with RXTX >> and where may the be available? > > Yeah, this is one of my concerns/beefs. There is little documentation > for RXTX and it isn't just the same as javaxcomm. > > I would be willing to help out writing docs for RXTX! Yes really... > esp if we can fix the Bluetooth issues. If you want to contribute documentation then the best place to do that is the wiki. If there is anything missing or that could be improved on then please do so. If there are any points that you would like to see improved, for which you don't have the knowledge then ask on the mailing list for a volunteer. Andre From florianmanschwetus at gmx.de Fri Aug 8 03:04:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Fri, 08 Aug 2008 11:04:14 +0200 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Message-ID: <489C0C0E.2020401@gmx.de> Agustin Mu?oz schrieb: > Hi, I'm still learning about serial communication and I have some > doubts. I've got this question about how to do the following thing in rxtx. > I have this hardware that connect to a PC using a serial port. These > hardware receives data from a telephone line, proccess it, and then send > it forward to the serial port. I've used a program named wincomm that > shows what information is send it through the serial port and I have the > nex behaviour: > > The hardware has a buffer where all data is stored, that cannot be sent > it through the seria port. > The program reads the first data send it by the hardware, and keep > reading the same data always. > There is a button in the application that says enable Ack, and when I > click, then the hardware start to send all the stored information, and > all the information is shown. > > I write a class, using rxtx that reads the serial port, and the same > thing happens, it remains reading the same (first) data all the time. > And I thing something like the enable Ack I'm missing. > How can I do this enable Ack from my java code using rxtx? Afaik, a look at man ascii reveals: Okt Dez Hex Char 006 6 06 ACK So, i hope this will do the job: send(6); florian > > Thanks in advance > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/5b4965f8/attachment-0001.bin From agusmunioz at gmail.com Fri Aug 8 16:31:00 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 19:31:00 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <489C0C0E.2020401@gmx.de> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> Message-ID: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Hi Florian, thanks for the answer. By send(6) you mean to get the port OutputStream and write a 6? I try that but it didn't work. Any suggestion? Thanks On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < florianmanschwetus at gmx.de> wrote: > Agustin Mu?oz schrieb: > > Hi, I'm still learning about serial communication and I have some doubts. >> I've got this question about how to do the following thing in rxtx. >> I have this hardware that connect to a PC using a serial port. These >> hardware receives data from a telephone line, proccess it, and then send it >> forward to the serial port. I've used a program named wincomm that shows >> what information is send it through the serial port and I have the nex >> behaviour: >> >> The hardware has a buffer where all data is stored, that cannot be sent >> it through the seria port. >> The program reads the first data send it by the hardware, and keep reading >> the same data always. >> There is a button in the application that says enable Ack, and when I >> click, then the hardware start to send all the stored information, and all >> the information is shown. >> >> I write a class, using rxtx that reads the serial port, and the same thing >> happens, it remains reading the same (first) data all the time. And I thing >> something like the enable Ack I'm missing. >> How can I do this enable Ack from my java code using rxtx? >> > Afaik, a look at man ascii reveals: > Okt Dez Hex Char > 006 6 06 ACK > So, i hope this will do the job: > send(6); > > florian > >> >> Thanks in advance >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/7f3fba42/attachment.html From agusmunioz at gmail.com Fri Aug 8 18:39:27 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 21:39:27 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Message-ID: <988288430808081739x7f9e7889id82591d5a9e2b4f6@mail.gmail.com> Ok, Florian, it works!! my problem was that I've been sending, through the OutputStream, the bytes of 6 as a string: out.write("6".getBytes()); but then I realized that you can write an int on an OuptuStream, so I tried that and It works: out.write(6); Thank you for the guidance!! On Fri, Aug 8, 2008 at 7:31 PM, Agustin Mu?oz wrote: > Hi Florian, thanks for the answer. By send(6) you mean to get the port > OutputStream and write a 6? > > I try that but it didn't work. > > Any suggestion? > > Thanks > > > On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < > florianmanschwetus at gmx.de> wrote: > >> Agustin Mu?oz schrieb: >> >> Hi, I'm still learning about serial communication and I have some doubts. >>> I've got this question about how to do the following thing in rxtx. >>> I have this hardware that connect to a PC using a serial port. These >>> hardware receives data from a telephone line, proccess it, and then send it >>> forward to the serial port. I've used a program named wincomm that shows >>> what information is send it through the serial port and I have the nex >>> behaviour: >>> >>> The hardware has a buffer where all data is stored, that cannot be sent >>> it through the seria port. >>> The program reads the first data send it by the hardware, and keep >>> reading the same data always. >>> There is a button in the application that says enable Ack, and when I >>> click, then the hardware start to send all the stored information, and all >>> the information is shown. >>> >>> I write a class, using rxtx that reads the serial port, and the same >>> thing happens, it remains reading the same (first) data all the time. And I >>> thing something like the enable Ack I'm missing. >>> How can I do this enable Ack from my java code using rxtx? >>> >> Afaik, a look at man ascii reveals: >> Okt Dez Hex Char >> 006 6 06 ACK >> So, i hope this will do the job: >> send(6); >> >> florian >> >>> >>> Thanks in advance >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/b918ab3d/attachment.html From florianmanschwetus at gmx.de Sat Aug 9 00:45:43 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Sat, 09 Aug 2008 08:45:43 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4899667C.6010706@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> Message-ID: <489D3D17.9090209@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >> Florian Manschwetus wrote: >>> Ok, sounds fine for the receiving problem. >>> But why i have to wait after each byte when sending a command squence? >>> (the for loop in send command) >> >> Hi Florian, >> I'd imagine you probably don't! You could send all bytes in one go and >> RXTX would send them. The problem is most probably the other end: >> perhaps it has a really small buffer, some non-standard UART, or a >> crazy timing issue. If you attach a terminal to your output and send >> all the bytes of a command in one go they should appear no problem. >> >> Regards, >> Michael Erskine. >> > correct with a terminal on the other end it works, my idea was that this > basic baud has some influence. Could some one explain what it is for? > > Florian To make it more clear, my problem is that i can't use: outputStream.write(byte[]); => Beamer doesn't understand the sequence. (mostly no answer when he answers then *001) when i use this construct instead: for (int i = 0; i < command.length; i++) { this.outputStream.write(command[i]); try { Thread.sleep(25); } catch (InterruptedException e) { // TODO Auto-generated catch block e.printStackTrace(); } } it works nearly reliable. So what could it be? This Basic Baud is what exactly? Florian -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080809/692304ee/attachment-0001.bin From rick_knight at rlknight.com Mon Aug 4 13:25:10 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Mon, 04 Aug 2008 12:25:10 -0700 Subject: [Rxtx] Sun's Comm API? Message-ID: <48975796.4010600@rlknight.com> I have an application that requires the javax compatible version of RXTX and Sun's comm api. I've been able to download and extract the version of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api anywhere. Can someone tell me where I can find it? Or maybe send me a copy? Also, when I try to build RXTX, configure and make complete successfully but make install failes with this error libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 I've never come accross this error before. How can I get past it? Thanks, Rick From bboyes at systronix.com Mon Aug 4 19:10:01 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:10:01 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48975796.4010600@rlknight.com> References: <48975796.4010600@rlknight.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/cb9c6167/attachment-0006.html From bboyes at systronix.com Mon Aug 4 19:12:37 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:12:37 -0600 Subject: [Rxtx] Towards an RXTX release - CSR BT/USB chipset In-Reply-To: <488FB7E7.8000802@gmail.com> References: <460801A4097E3D4CA04CC64EE648584806C56CF0@ism-mail03.corp.ad.wrs.com> <13557-75390@sneakemail.com> <20980-23424@sneakemail.com> <488FB7E7.8000802@gmail.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/52236088/attachment-0006.html From tjarvi at qbang.org Mon Aug 4 19:42:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 19:42:21 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: On Mon, 4 Aug 2008, Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: > I have an application that requires the javax compatible > version of RXTX > and Sun's comm api. I've been able to download and extract > the version > of RXTX that I need (2.0-7pre2) but I can't find Sun's camm > api > anywhere. Can someone tell me where I can find it? Or maybe > send me a > > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm port > support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have just > a ZIP with only the .class JAR file - no source or docs), has a readme > with these comments: > > This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release.? The 2.0.3 release itself is > no longer distributed.? comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project.? The RxTx project (http://www.rxtx.org ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org) was opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support.? Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins.? Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > ? > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > I hope that is helpful! > It would be nice to work with Sun to resolve those longstanding issues. But it may not be practical unless the process goes as fast and painless as the grandfathering of commapi did. Another option may be the old kaffe extensions that moved to gnu classpathx. These don't have the native libraries but should provide the 2.0 interface and the javax.comm.properties mechansim for SPI. http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Mon Aug 4 20:23:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Mon, 04 Aug 2008 20:23:57 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4897B9BD.5070809@ergotech.com> Has there been any work/would it be possible, to layer a javacomm look-alike on top of the GNU code? The goal is not to move the javax code forward, but to emulate the "legacy" javax packages for people who still need this. Jim Trent Jarvi wrote: > On Mon, 4 Aug 2008, Bruce Boyes wrote: > >> At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible >> version of RXTX >> and Sun's comm api. I've been able to download and extract >> the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm >> api >> anywhere. Can someone tell me where I can find it? Or maybe >> send me a >> >> >> javaxcomm has had a sort of on-again off-again history. The windoze >> version has been languishing for years (literally) but there are newer >> versions for other OS's. >> >> We try to keep links on one of our help pages current: >> http://www.practicalembeddedjava.com/tools/javatools_list.html >> which gets you to here: >> http://java.sun.com/products/javacomm/ >> where it says in fact they no longer even support Windows and Mac: >> "Implementations of the API are currently available for Solaris SPARC, >> Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so >> someone could support it. But I guess that's part of the reason RXTX >> exists! >> >> So one of Sun's own products, SunSPOT, has to use RXTX to get comm port >> support. >> >> The version we use is 2.0 from 11/15/1998. I have posted it on our >> website, which is within the terms of the license agreement contained >> therein (as I understand it). >> >> The last version of javaxcomm for Windows, 2.0.3, (for which I have just >> a ZIP with only the .class JAR file - no source or docs), has a readme >> with these comments: >> >> This distribution contains the comm.jar file original part >> of the COMMAPI 2.0.3 release. The 2.0.3 release itself is >> no longer distributed. comm.jar, which contains the comm >> API java class files (eg. Sun's binary implementation of the >> interface classes), is being made available, unsupported, >> with no obligation to fix bugs, at the request of the RXTX >> project. The RxTx project (http://www.rxtx.org ), uses the >> comm.jar class files, but provides their own native library >> components to provide support for other platforms. >> >> The 2.0.3 comm.jar is being provided in this way because >> as of COMMAPI 3.x, the java binary implementation forked and >> became incompatible with the RxTx project's native code. >> Due to the lack of a clear business case, and to resource >> constraints, no additional resources are being >> provided to provide an alternative engineering solution >> at the time of writing. >> >> RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: >> >> Ultimately the COMMAPI would be better served if a Java >> Community Process JSR (http://www.jcp.org) was opened and >> the COMMAPI was rearchitected to provide a more pluggable >> framework to improve cross-platform support. Such an >> architecture would embody a better defined and better >> documented SPI interface, including a way for comm. ports >> to be revealed to the client application through the API >> via platform-aware plugins. Similarly, native code used >> to access comm port in general could be handled more >> flexibly using a plugin model, whereby on any platform, >> multiple native modules could be in use simultaneously. >> >> Since there are now various ways serial ports can be implemented >> and accessed, modular comm. port JNI native libraries would be >> of benefit insofar as removing the burden of over-generalization >> from any single native component, or inversely, by relieving the >> implicit constraint that comm. drivers be accessed only via a >> monolithic mechanism, such as the UNIX vnode interface. >> >> paul.klissner at sun.com >> 6/10/06 >> >> I hope that is helpful! >> > > It would be nice to work with Sun to resolve those longstanding issues. > But it may not be practical unless the process goes as fast and painless > as the grandfathering of commapi did. > > Another option may be the old kaffe extensions that moved to gnu > classpathx. These don't have the native libraries but should provide > the 2.0 interface and the javax.comm.properties mechansim for SPI. > > http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Mon Aug 4 21:09:15 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 21:09:15 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? Message-ID: Hi Jim, I will not step into the javax.comm namespace without Sun's explicite permission. I fully understand the pain point you are trying to address. In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm Linux) - which remains an integral part of rxtx. At the time it was a win for Sun and rxtx. The Sun commapi license is/was fairly clear that rxtx should not step into that namespace. It made sense as Sun was active in that space and rxtx may go into another namespace - it was an experiment in working with Sun. This may sound silly looking at something that happened almost 10 years ago. In a community of respect which Sun helped create, there is no question about what to do. I hope eventually Sun will step up and do a right thing too. I agree that this is hurting the API more than helping it. There are also questions about how to replace the API in the long term which includes HID support which isn't going well so far. Others that can't even look at Sun's javax.comm today and can look at Kaffe's contribution to classpathx can easily work around such restrictions. On Mon, 4 Aug 2008, Jim Redman wrote: > Has there been any work/would it be possible, to layer a javacomm > look-alike on top of the GNU code? > > The goal is not to move the javax code forward, but to emulate the > "legacy" javax packages for people who still need this. > > Jim > > Trent Jarvi wrote: >> >> It would be nice to work with Sun to resolve those longstanding issues. >> But it may not be practical unless the process goes as fast and painless >> as the grandfathering of commapi did. >> >> Another option may be the old kaffe extensions that moved to gnu >> classpathx. These don't have the native libraries but should provide >> the 2.0 interface and the javax.comm.properties mechansim for SPI. >> >> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From florianmanschwetus at gmx.de Tue Aug 5 05:04:46 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 13:04:46 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: References: <48971C1F.9020806@gmx.de> Message-ID: <489833CE.1040801@gmx.de> Just look at sendCommand in this method I have to place a Thread.sleep(20) after each byte send to get working. Even the event based receive doesn't work fine but this could be may stupidness. The specifikation document (it is on the last pages of the manual) for the beamer could be found on: http://www.optoma.co.uk/support.aspx Florian Manschwetus Trent Jarvi schrieb: > > Hi Florian > > Sorry for the top post in advance. I worry you may not see my answer > under all your code :) > > I have not received this email before. This is 500k of code which I > don't have time to read. I can spend about 5 min on each hobby email > and still get to work in the morning. I have a couple suggestions for > how to get an answer. > > First, cut out your comments and extra code so you can demonstrate the > question (I might even glance and see what is wrong then). Don't go for > a working final product. Isolate the problem using a simple program and > then ask with that as an example. If I did what you just did, I'd have > to post 3/4 of a million lines of code :) > > Second, join the rxtx mail-list and ask there. This will give you 100x > more eyes. I'll also read and try to follow. > > -- > taj > > > > On Mon, 4 Aug 2008, Florian Manschwetus wrote: > >> It could be that my university account is blocked by filters so >> resending from here. >> >> >> Topic is to control Optoma HD80 beamer using rs232 serial chat. >> This code is able to detect power state and switch the beamer on / off. >> connected is the beamer using a digitus usb 2.0 serial adapter with an >> FT232 USB-Serial adapter the systems architecture is amd64. >> >> Please take a look in the sendCommand routine i have to place theire >> those Thread.sleep to get it working. >> Now the question is this correct or is there a better way to get this >> working correctly? >> >> In the javadoc coming with the install i found this: >> setBaudBase >> >> public boolean setBaudBase(int BaudBase) >> throws UnsupportedCommOperationException, >> java.io.IOException >> >> Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 >> before using. >> >> could this explain the error? >> I attached my java source and the protocol description for the beamer >> (available on vendor website). >> >> thx, >> Florian Manschwetus >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: TestRS232.java Type: text/x-java Size: 9143 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0012.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0013.bin From michael.erskine at ketech.com Tue Aug 5 05:53:49 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Tue, 5 Aug 2008 12:53:49 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489833CE.1040801@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> > Just look at sendCommand in this method I have to place a > Thread.sleep(20) after each byte send to get working. Even the event > based receive doesn't work fine but this could be may stupidness. Hi Florian, Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. Regards, Michael Erskine. From florianmanschwetus at gmx.de Tue Aug 5 07:28:15 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:28:15 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> Message-ID: <4898556F.8000208@gmx.de> Michael Erskine schrieb: >> Just look at sendCommand in this method I have to place a >> Thread.sleep(20) after each byte send to get working. Even the event >> based receive doesn't work fine but this could be may stupidness. > > Hi Florian, > > Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. > > Regards, > Michael Erskine. > Ok, sounds fine for the receiving problem. But why i have to wait after each byte when sending a command squence? (the for loop in send command) Florian > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/284f350c/attachment-0005.bin From florianmanschwetus at gmx.de Tue Aug 5 07:44:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:44:14 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <4898592E.2020908@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >>> Just look at sendCommand in this method I have to place a >>> Thread.sleep(20) after each byte send to get working. Even the event >>> based receive doesn't work fine but this could be may stupidness. >> >> Hi Florian, >> >> Yes, naturally you'll have to wait for a response from the other end. >> Why not wait for notification from the event thread perhaps using a >> BlockingDeque rather than your LinkedList. Generally I >> try to decouple all input and output streams: in your case your >> application is operating synchronously like the "expect" program >> (http://expect.nist.gov/) so waits (or timeouts) will need to be >> factored in. >> >> Regards, >> Michael Erskine. >> > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) > > Florian Furthermore there is this basic baud with this confusing javadoc entry: public boolean setBaudBase(int BaudBase) throws UnsupportedCommOperationException, java.io.IOException Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 before using. maybe this could explain something Florian >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/006c7425/attachment-0005.bin From jredman at ergotech.com Tue Aug 5 09:13:36 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 05 Aug 2008 09:13:36 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: Message-ID: <48986E20.3060104@ergotech.com> Trent, So two issues: 1) Technically I'm still not sure how easy/practical a layer would be. The problems are always classes like listeners, and wrapping returns of gnu.io classes. I really see it as a "delegate" type of concept. Any thoughts or ideas of the practicality of this approach? The idea is not to modify RXTX. 2) Javax. The javax namespace does seem to be in widespread use outside of Sun (the same is true for the java namespace). The classpath extensions, or some other location, should be interested in a JavaComm implementation even if it does have dependencies on RXTX. Would you have any philosophical objection to an approach like that? Of course, I suspect it might be better if someone with that authority at Sun would admit that the javax namespace is already in the wild and that there is no problem with it being used within RXTX. Jim Trent Jarvi wrote: > Hi Jim, > > I will not step into the javax.comm namespace without Sun's explicite > permission. I fully understand the pain point you are trying to address. > > In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm > Linux) - which remains an integral part of rxtx. At the time it was a win for > Sun and rxtx. > > The Sun commapi license is/was fairly clear that rxtx should not step into that > namespace. It made sense as Sun was active in that space and rxtx may go into > another namespace - it was an experiment in working with Sun. > > This may sound silly looking at something that happened almost 10 years ago. > In a community of respect which Sun helped create, there is no question about > what to do. I hope eventually Sun will step up and do a right thing too. > > I agree that this is hurting the API more than helping it. There are also > questions about how to replace the API in the long term which includes HID > support which isn't going well so far. > > Others that can't even look at Sun's javax.comm today and can look at Kaffe's > contribution to classpathx can easily work around such restrictions. > > On Mon, 4 Aug 2008, Jim Redman wrote: > >> Has there been any work/would it be possible, to layer a javacomm >> look-alike on top of the GNU code? >> >> The goal is not to move the javax code forward, but to emulate the >> "legacy" javax packages for people who still need this. >> >> Jim >> >> Trent Jarvi wrote: >>> It would be nice to work with Sun to resolve those longstanding issues. >>> But it may not be practical unless the process goes as fast and painless >>> as the grandfathering of commapi did. >>> >>> Another option may be the old kaffe extensions that moved to gnu >>> classpathx. These don't have the native libraries but should provide >>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>> >>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From sandeep at genevasoftech.com Tue Aug 5 11:18:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Tue, 05 Aug 2008 22:48:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <48988B6C.5080409@genevasoftech.com> Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. *-- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/ad20f1cb/attachment-0005.html From Martin.Oberhuber at windriver.com Tue Aug 5 13:30:17 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Tue, 5 Aug 2008 21:30:17 +0200 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Sandeep, shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on Sol7 but I've successfully run it on Sol9 and Sol10. Or is your request really about a native 64bit variant? I'm afraid that then you're out of luck since I think that quite a bit of RXTX is not yet ready for 64 bit. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Sandeep Kumar K Sent: Tuesday, August 05, 2008 7:19 PM To: rxtx at qbang.org Subject: [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so for Solaris 9 Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. -- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/81b7f988/attachment-0005.html From tjarvi at qbang.org Tue Aug 5 22:38:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 22:38:34 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 5 Aug 2008, Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built > on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid that > then > you're out of luck since I think that quite a bit of RXTX is not yet > ready > for 64 bit. > While rxtx-2.1-7 probably has problems, The CVS code should be OK for 64 bit Solaris. If it isn't, let me know and I'll find which patch is missing. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Aug 5 23:13:00 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 23:13:00 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48986E20.3060104@ergotech.com> References: <48986E20.3060104@ergotech.com> Message-ID: On Tue, 5 Aug 2008, Jim Redman wrote: > Trent, > > So two issues: > > 1) Technically I'm still not sure how easy/practical a layer would be. The > problems are always classes like listeners, and wrapping returns of gnu.io > classes. I really see it as a "delegate" type of concept. Any thoughts or > ideas of the practicality of this approach? The idea is not to modify RXTX. I have not put too much thought into this. I assume you want what rxtx 2.0 provided to tie into javax.comm implementations. More classes could be added to rxtx 2.1-7 for SPI support. Maintaining rxtx-2.0 could also be handed to someone if they like. > > 2) Javax. The javax namespace does seem to be in widespread use outside of > Sun (the same is true for the java namespace). The classpath extensions, or > some other location, should be interested in a JavaComm implementation even > if it does have dependencies on RXTX. Would you have any philosophical > objection to an approach like that? > No problems. Classpathx would be a possible place to do it. I'd suggest thinking twice about what this involves in practical terms. You would be wanting to revive the 2.0 API while Sun is at 3.0 and grandfathering the JSR. This undermines the main reason (established api) for using the javax.comm namespace and does not leave such a project in a good position. The only win I see here is maintaining support for applications that can't migrate namespaces. Not that that isn't important. At some point it is going to be less work to just edit the bytecode :) Such a javax.comm effort would also be signing up new projects that decided to use the work up for concerns they probably will not understand or expect. That probably isn't a good path to facilitate for new projects at this time. We will put a good faith effort to work well with others but keep in mind the project has limited bandwidth for such efforts. > Of course, I suspect it might be better if someone with that authority at Sun > would admit that the javax namespace is already in the wild and that there is > no problem with it being used within RXTX. > > Jim > > Trent Jarvi wrote: >> Hi Jim, >> >> I will not step into the javax.comm namespace without Sun's explicite >> permission. I fully understand the pain point you are trying to address. >> >> In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java >> Comm Linux) - which remains an integral part of rxtx. At the time it was a >> win for Sun and rxtx. >> >> The Sun commapi license is/was fairly clear that rxtx should not step into >> that namespace. It made sense as Sun was active in that space and rxtx may >> go into another namespace - it was an experiment in working with Sun. >> >> This may sound silly looking at something that happened almost 10 years >> ago. In a community of respect which Sun helped create, there is no >> question about what to do. I hope eventually Sun will step up and do a >> right thing too. >> >> I agree that this is hurting the API more than helping it. There are also >> questions about how to replace the API in the long term which includes HID >> support which isn't going well so far. >> >> Others that can't even look at Sun's javax.comm today and can look at >> Kaffe's contribution to classpathx can easily work around such >> restrictions. >> >> On Mon, 4 Aug 2008, Jim Redman wrote: >> >>> Has there been any work/would it be possible, to layer a javacomm >>> look-alike on top of the GNU code? >>> >>> The goal is not to move the javax code forward, but to emulate the >>> "legacy" javax packages for people who still need this. >>> >>> Jim >>> >>> Trent Jarvi wrote: >>>> It would be nice to work with Sun to resolve those longstanding issues. >>>> But it may not be practical unless the process goes as fast and painless >>>> as the grandfathering of commapi did. >>>> >>>> Another option may be the old kaffe extensions that moved to gnu >>>> classpathx. These don't have the native libraries but should provide >>>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>>> >>>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From sandeep at genevasoftech.com Wed Aug 6 00:03:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Wed, 06 Aug 2008 11:33:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: <48993EB8.30107@genevasoftech.com> Thank you Mr. Martin for your suggestion. The native file which is given in rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am getting the following error . Any suggestions to solve this issue. I am using Solaris SPARC 64 bit machine. ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) thrown while loading gnu.io.RXTXCommDriver Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(Unknown Source) at java.lang.ClassLoader.loadLibrary(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) at com.ReadFromModem.main(ReadFromModem.java:84) * * *Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid > that then > you're out of luck since I think that quite a bit of RXTX is not yet ready > for 64 bit. > > Cheers, > -- > *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > ------------------------------------------------------------------------ > *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On > Behalf Of *Sandeep Kumar K > *Sent:* Tuesday, August 05, 2008 7:19 PM > *To:* rxtx at qbang.org > *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so > for Solaris 9 > > Hi, > > Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 > bit machine. The librxtxSerial.so given in website is for Solaris 8. > > *-- > > Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/1e920343/attachment-0005.html From tjarvi at qbang.org Wed Aug 6 00:21:42 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 00:21:42 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <48993EB8.30107@genevasoftech.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> <48993EB8.30107@genevasoftech.com> Message-ID: Hi Sandeep You may be out of luck unless you can compile the 2.1 src in CVS (requires gnu make and gcc). But you could try the ToyBox(R)(TM) which is a collection of WiLdLy untested cross compiled 2.1-7 binaries covering everything from the ibm z series to embeded arm/ppc. To give an idea how poorly these are tested, I don't even know if z series machines have a serial port. ftp://www.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Solaris They should at least match the binary types. Actually, I think if you use the rxtx jar from CVS with that file, it should 'work' as the fix for 64 bits was in java not the native code. You could just cd rxtx*/src; javac *.java then jar -cf RXTXcomm.jar `find -name \*.class` to create the hybrid which will complain about version information a bit. On Wed, 6 Aug 2008, Sandeep Kumar K wrote: > Thank you Mr. Martin for your suggestion. The native file which is given in > rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am > getting the following error . > Any suggestions to solve this issue. > I am using Solaris SPARC 64 bit machine. > > ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar > java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 > (Possible cause: architecture word > width mismatch) thrown while loading gnu.io.RXTXCommDriver > Exception in thread "main" java.lang.UnsatisfiedLinkError: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF > class: ELFCLASS64 (Possible cause: > architecture word width mismatch) > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(Unknown Source) > at java.lang.ClassLoader.loadLibrary(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > at com.ReadFromModem.main(ReadFromModem.java:84) > > * > * > > *Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > > > Oberhuber, Martin wrote: >> Sandeep, >> shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse >> variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on >> Sol7 but I've successfully run it on Sol9 and Sol10. >> Or is your request really about a native 64bit variant? I'm afraid that >> then >> you're out of luck since I think that quite a bit of RXTX is not yet ready >> for 64 bit. >> Cheers, >> -- >> *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> ------------------------------------------------------------------------ >> *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On >> Behalf Of *Sandeep Kumar K >> *Sent:* Tuesday, August 05, 2008 7:19 PM >> *To:* rxtx at qbang.org >> *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so >> for Solaris 9 >> >> Hi, >> >> Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 >> bit machine. The librxtxSerial.so given in website is for Solaris 8. >> >> *-- >> Thanks & Regards >> >> Sandeep Kumar K >> Sr. Software Engineer >> Geneva Software Technologies >> Whitefield, Bangalore >> Mob : 9880193454* >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> From michael.erskine at ketech.com Wed Aug 6 01:39:28 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 6 Aug 2008 08:39:28 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Florian Manschwetus wrote: > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) Hi Florian, I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. Regards, Michael Erskine. From florianmanschwetus at gmx.de Wed Aug 6 02:53:16 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 06 Aug 2008 10:53:16 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Message-ID: <4899667C.6010706@gmx.de> Michael Erskine schrieb: > Florian Manschwetus wrote: >> Ok, sounds fine for the receiving problem. >> But why i have to wait after each byte when sending a command squence? >> (the for loop in send command) > > Hi Florian, > I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. > > Regards, > Michael Erskine. > correct with a terminal on the other end it works, my idea was that this basic baud has some influence. Could some one explain what it is for? Florian > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/c2b4fa84/attachment-0005.bin From rick_knight at rlknight.com Wed Aug 6 13:01:07 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:01:07 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F4F3.3020707@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > I have an application (Readerware) that uses RXTX with Javax to access the serial port. This used to work fine under previous Linux' and Java, but something has changed, I assume with Java itself , that is causing the application to fail with a link error. The application is not able to find librxtxSerialParallel.so. RXTX supplies librxtxSerial.so and librxtxParallel.so, but not librxtxSerialParallel.so. Where can I get librxtxSerialParallel.so, or do I need it? Is something else causing the lib to not be found? Thanks, Rick Knight From rick_knight at rlknight.com Wed Aug 6 13:17:55 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:17:55 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F8E3.5060400@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Thanks for the reply. The developer of the app I'm trying to use (Readerware) has sent me a copy of the comm.api and I've copied the library (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar into the proper places. When I try to run the application, I get this error... Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: /usr/lib/libSolarisSerialParallel.so: /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not little-endian (Possible cause: endianness mismatch) Caught java.lang.UnsatisfiedLinkError: com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I while loading driver com.sun.comm.SolarisDriver Is there a way around this error? Thanks again, Rick Knight From jlar310 at gmail.com Wed Aug 6 13:37:42 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 14:37:42 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899F8E3.5060400@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > The developer of the app I'm trying to use (Readerware) has sent me a > copy of the comm.api and I've copied the library > (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar > into the proper places. When I try to run the application, I get this > error... > > Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: > /usr/lib/libSolarisSerialParallel.so: > /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not > little-endian (Possible cause: endianness mismatch) > Caught java.lang.UnsatisfiedLinkError: > com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I > > while loading driver com.sun.comm.SolarisDriver > > Is there a way around this error? What host OS are you running? From your original post it looks like 32 bit Linux. The libSolarisSerialParallel.so file is for Sun Solaris and will vary depending on the underlying hardware architecture as well. Sorry for the double post Rick, but I failed to send this to the list the first time... -- Jeff From rick_knight at rlknight.com Wed Aug 6 13:44:29 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:44:29 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: <4899FF1D.9030504@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > > >> The developer of the app I'm trying to use (Readerware) has sent me a >> copy of the comm.api and I've copied the library >> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >> into the proper places. When I try to run the application, I get this >> error... >> >> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >> /usr/lib/libSolarisSerialParallel.so: >> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >> little-endian (Possible cause: endianness mismatch) >> Caught java.lang.UnsatisfiedLinkError: >> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >> >> while loading driver com.sun.comm.SolarisDriver >> >> Is there a way around this error? >> > > What host OS are you running? From your original post it looks like 32 > bit Linux. > > The libSolarisSerialParallel.so file is for Sun Solaris and will vary > depending on the underlying hardware architecture as well. > > I'm running Kubuntu Linux (debian based). It's 32 bit. Rick Knight From jlar310 at gmail.com Wed Aug 6 15:33:23 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 16:33:23 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > I don't think Sun did binary libraries for Linux in the 2.0 version. Can someone with more historical experience than I confirm that? I recently tried to port a Comm API application from Solaris sparc to Linux x86 and likewise could not get my hands on the binary libraries. I eventually just re-wrote the code to use the gnu namespace packages and rxtx 2.1. What I don't understand is why your application vendor does not provide everything you need to run their software. FYI: I have librxtxParallel.so and librxtxSerial.so installed at JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is /usr/java/default which is actually a softlink to /usr/java/jre1.6.0_05. -- Jeff From defiantlew at yahoo.com.au Wed Aug 6 16:29:33 2008 From: defiantlew at yahoo.com.au (Lew L) Date: Thu, 7 Aug 2008 08:29:33 +1000 Subject: [Rxtx] Sun's Comm API Documentation References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> Message-ID: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> As a matter of interest is the Sun Comm API documentation available somewhere? I have tried the Sun site but it seems to have been removed. Unless I have missed the documentation for RXTX? I javadocced the RXTX source but information (to me) is minimal. Somewhere I got the impression that the Sun Comm API docs is, or was, compatible with RXTX, what is the best docs to use in conjuntion with RXTX and where may the be available? Cheers Lew From rick_knight at rlknight.com Wed Aug 6 17:18:33 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:18:33 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A3149.4050306@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff I'm not sure if I posted this here or not, but when I try to build RXTX from source I get this install error... make all-am make[1]: Entering directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' make[1]: Nothing to be done for `all-am'. make[1]: Leaving directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 Can you tell me how to get past this error and get RXTX built and installed? Thanks, Rick From bboyes at systronix.com Wed Aug 6 17:40:12 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Wed, 06 Aug 2008 17:40:12 -0600 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: At 16:29 08/06/2008, Lew L wrote: >As a matter of interest is the Sun Comm API documentation available >somewhere? I have tried the Sun site but it seems to have been removed. It's in the file we have posted, link in prev email (sorry, in a huge hurry right now). Javadocs definitely there. >Unless I have missed the documentation for RXTX? I javadocced the RXTX >source but information (to me) is minimal. >Somewhere I got the impression that the Sun Comm API docs is, or was, >compatible with RXTX, what is the best docs to use in conjuntion with RXTX >and where may the be available? Yeah, this is one of my concerns/beefs. There is little documentation for RXTX and it isn't just the same as javaxcomm. I would be willing to help out writing docs for RXTX! Yes really... esp if we can fix the Bluetooth issues. best regards Bruce >Cheers >Lew > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx ------- WWW.SYSTRONIX.COM ---------- Real embedded Java and much more +1-801-534-1017 Salt Lake City, USA From rick_knight at rlknight.com Wed Aug 6 17:54:08 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:54:08 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A39A0.2090309@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff, I would like for my vendor to switch to rxtx 2.1. It would make things much easier for me. I'm not sure why he's still using the javax compatible code. He's a small operation. Re-writing the code to use gnu namespace sounds like a major overhaul. Was it? Thanks, Rick From tjarvi at qbang.org Wed Aug 6 21:35:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:35:12 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: >> >>> Jeff wrote: >>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>>> >>>> >>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things > much easier for me. I'm not sure why he's still using the javax > compatible code. He's a small operation. Re-writing the code to use gnu > namespace sounds like a major overhaul. Was it? > Hi Jeff, The changes are fairly mechanical. Imports need to change and any explicite use of the namespace needs to change such as catching an exception. The following script was made for maintaining rxtx 2.0 but can apply to other needs. It is in the contrib dir with rxtx source. #!/bin/sh # Don't use! :) # # Sat, 03 May 2003 16:45:08 Modifications from J?rg Weule # Create a ed-cmd for the change of one pattern # case $1 in gnu) X=g/javax_comm/s+javax_comm+gnu_io+g ;; javax) X=g/gnu_io/s+gnu_io+javax_comm+g ;; *) echo;echo;echo From the top rxtx directory run;echo;echo -e \\t./ChangePackage.sh gnu;echo -e \\t\\tor;echo -e \\t./ChangePackage.sh javax;echo;echo; exit 0 ;; esac # # ed will be used to keep the owner and mode of the files unchanged. # We have run the ed-script for the characters '.' '/' as well. # "tr _ $D" do the change. # find . -type f -a -print | grep -v $0 | (while read F ; do ( echo $X; echo $X| tr _ /; echo $X| tr _ .; echo w; echo q ) | ed $F 2>&1 >/dev/null done ) # # Now we do little changes at the Makefiles. Hope that all we need. # find . -name Makefile\* -a -print | (while read F ; do cat < References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: On Thu, 7 Aug 2008, Lew L wrote: > As a matter of interest is the Sun Comm API documentation available > somewhere? I have tried the Sun site but it seems to have been removed. > > Unless I have missed the documentation for RXTX? I javadocced the RXTX > source but information (to me) is minimal. > Somewhere I got the impression that the Sun Comm API docs is, or was, > compatible with RXTX, what is the best docs to use in conjuntion with RXTX > and where may the be available? > Hi Lew, The documentation on Sun's website is accurate. The changes that are problematic in 3.0 are on the backside which rxtx used to plug into. http://java.sun.com/products/javacomm/reference/api/index.html CommPortIdentifier may have some minor differences (judging by the authors notes). -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Aug 6 21:46:08 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:46:08 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > If javax.comm.properties is properly installed and you are using a 2.0 version of Sun's commapi with rxtx 2.0, you should not see the library attempt to load libSolarisSerialParallel.so. Sun CommAPI 3.0 will not work with any version of rxtx as it is hard coded to use the shared library. See the INSTALL file with rxtx-2.0 source for more help with the properties file. -- Trent Jarvi tjarvi at qbang.org From jlar310 at gmail.com Thu Aug 7 06:32:06 2008 From: jlar310 at gmail.com (Jeff) Date: Thu, 7 Aug 2008 07:32:06 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > Jeff wrote: >> >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >> wrote: >> >>> >>> Jeff wrote: >>> >>>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>> wrote: >>>> >>>> >>>> >>>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things much > easier for me. I'm not sure why he's still using the javax compatible code. > He's a small operation. Re-writing the code to use gnu namespace sounds like > a major overhaul. Was it? I found it quite easy. In fact, in order to accommodate the transition, I actually separated all of the code that deals directly with the Comm API or RXTX into a helper class. The helper class was then coded to use reflection to determine which library was available and then instantiate the necessary objects. No direct imports of either library are used. The main application just needs to get it's hands on the IO streams and need not deal directly with the libraries. Other programs may not be so simple... But this doesn't really help you unless your vendor forks over the source code... -- Jeff From rick_knight at rlknight.com Thu Aug 7 09:47:12 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Thu, 07 Aug 2008 08:47:12 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: <489B1900.10108@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >>> wrote: >>> >>> >>>> Jeff wrote: >>>> >>>> >>>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>>> copy of the comm.api and I've copied the library >>>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>>> into the proper places. When I try to run the application, I get this >>>>>> error... >>>>>> >>>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>>> /usr/lib/libSolarisSerialParallel.so: >>>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>>> little-endian (Possible cause: endianness mismatch) >>>>>> Caught java.lang.UnsatisfiedLinkError: >>>>>> >>>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>>> >>>>>> while loading driver com.sun.comm.SolarisDriver >>>>>> >>>>>> Is there a way around this error? >>>>>> >>>>>> >>>>>> >>>>> What host OS are you running? From your original post it looks like 32 >>>>> bit Linux. >>>>> >>>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>>> depending on the underlying hardware architecture as well. >>>>> >>>>> >>>>> >>>>> >>>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>>> >>>> >>>> >>> I don't think Sun did binary libraries for Linux in the 2.0 version. >>> Can someone with more historical experience than I confirm that? >>> >>> I recently tried to port a Comm API application from Solaris sparc to >>> Linux x86 and likewise could not get my hands on the binary libraries. >>> I eventually just re-wrote the code to use the gnu namespace packages >>> and rxtx 2.1. >>> >>> What I don't understand is why your application vendor does not >>> provide everything you need to run their software. >>> >>> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >>> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >>> /usr/java/default which is actually a softlink to >>> /usr/java/jre1.6.0_05. >>> >>> >>> >> Jeff, >> >> I would like for my vendor to switch to rxtx 2.1. It would make things much >> easier for me. I'm not sure why he's still using the javax compatible code. >> He's a small operation. Re-writing the code to use gnu namespace sounds like >> a major overhaul. Was it? >> > > I found it quite easy. In fact, in order to accommodate the > transition, I actually separated all of the code that deals directly > with the Comm API or RXTX into a helper class. The helper class was > then coded to use reflection to determine which library was available > and then instantiate the necessary objects. No direct imports of > either library are used. The main application just needs to get it's > hands on the IO streams and need not deal directly with the libraries. > Other programs may not be so simple... > > But this doesn't really help you unless your vendor forks over the > source code... > > Jeff, This may not help me directly, but I'm going to forward this thread to the vendor. I think he'll be open to making things work. Thanks again, Rick Knight From agusmunioz at gmail.com Thu Aug 7 16:39:51 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Thu, 7 Aug 2008 19:39:51 -0300 Subject: [Rxtx] How to send ack? Message-ID: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Hi, I'm still learning about serial communication and I have some doubts. I've got this question about how to do the following thing in rxtx. I have this hardware that connect to a PC using a serial port. These hardware receives data from a telephone line, proccess it, and then send it forward to the serial port. I've used a program named wincomm that shows what information is send it through the serial port and I have the nex behaviour: The hardware has a buffer where all data is stored, that cannot be sent it through the seria port. The program reads the first data send it by the hardware, and keep reading the same data always. There is a button in the application that says enable Ack, and when I click, then the hardware start to send all the stored information, and all the information is shown. I write a class, using rxtx that reads the serial port, and the same thing happens, it remains reading the same (first) data all the time. And I thing something like the enable Ack I'm missing. How can I do this enable Ack from my java code using rxtx? Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080807/e0a0f9a1/attachment-0003.html From ajmas at sympatico.ca Thu Aug 7 18:26:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 7 Aug 2008 20:26:41 -0400 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: <4BF42297-81E2-4BB8-A89F-1D43588379AE@sympatico.ca> On 6-Aug-08, at 19:40 , Bruce Boyes wrote: >> Unless I have missed the documentation for RXTX? I javadocced the >> RXTX >> source but information (to me) is minimal. >> Somewhere I got the impression that the Sun Comm API docs is, or was, >> compatible with RXTX, what is the best docs to use in conjuntion >> with RXTX >> and where may the be available? > > Yeah, this is one of my concerns/beefs. There is little documentation > for RXTX and it isn't just the same as javaxcomm. > > I would be willing to help out writing docs for RXTX! Yes really... > esp if we can fix the Bluetooth issues. If you want to contribute documentation then the best place to do that is the wiki. If there is anything missing or that could be improved on then please do so. If there are any points that you would like to see improved, for which you don't have the knowledge then ask on the mailing list for a volunteer. Andre From florianmanschwetus at gmx.de Fri Aug 8 03:04:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Fri, 08 Aug 2008 11:04:14 +0200 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Message-ID: <489C0C0E.2020401@gmx.de> Agustin Mu?oz schrieb: > Hi, I'm still learning about serial communication and I have some > doubts. I've got this question about how to do the following thing in rxtx. > I have this hardware that connect to a PC using a serial port. These > hardware receives data from a telephone line, proccess it, and then send > it forward to the serial port. I've used a program named wincomm that > shows what information is send it through the serial port and I have the > nex behaviour: > > The hardware has a buffer where all data is stored, that cannot be sent > it through the seria port. > The program reads the first data send it by the hardware, and keep > reading the same data always. > There is a button in the application that says enable Ack, and when I > click, then the hardware start to send all the stored information, and > all the information is shown. > > I write a class, using rxtx that reads the serial port, and the same > thing happens, it remains reading the same (first) data all the time. > And I thing something like the enable Ack I'm missing. > How can I do this enable Ack from my java code using rxtx? Afaik, a look at man ascii reveals: Okt Dez Hex Char 006 6 06 ACK So, i hope this will do the job: send(6); florian > > Thanks in advance > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/5b4965f8/attachment-0003.bin From agusmunioz at gmail.com Fri Aug 8 16:31:00 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 19:31:00 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <489C0C0E.2020401@gmx.de> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> Message-ID: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Hi Florian, thanks for the answer. By send(6) you mean to get the port OutputStream and write a 6? I try that but it didn't work. Any suggestion? Thanks On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < florianmanschwetus at gmx.de> wrote: > Agustin Mu?oz schrieb: > > Hi, I'm still learning about serial communication and I have some doubts. >> I've got this question about how to do the following thing in rxtx. >> I have this hardware that connect to a PC using a serial port. These >> hardware receives data from a telephone line, proccess it, and then send it >> forward to the serial port. I've used a program named wincomm that shows >> what information is send it through the serial port and I have the nex >> behaviour: >> >> The hardware has a buffer where all data is stored, that cannot be sent >> it through the seria port. >> The program reads the first data send it by the hardware, and keep reading >> the same data always. >> There is a button in the application that says enable Ack, and when I >> click, then the hardware start to send all the stored information, and all >> the information is shown. >> >> I write a class, using rxtx that reads the serial port, and the same thing >> happens, it remains reading the same (first) data all the time. And I thing >> something like the enable Ack I'm missing. >> How can I do this enable Ack from my java code using rxtx? >> > Afaik, a look at man ascii reveals: > Okt Dez Hex Char > 006 6 06 ACK > So, i hope this will do the job: > send(6); > > florian > >> >> Thanks in advance >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/7f3fba42/attachment-0002.html From agusmunioz at gmail.com Fri Aug 8 18:39:27 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 21:39:27 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Message-ID: <988288430808081739x7f9e7889id82591d5a9e2b4f6@mail.gmail.com> Ok, Florian, it works!! my problem was that I've been sending, through the OutputStream, the bytes of 6 as a string: out.write("6".getBytes()); but then I realized that you can write an int on an OuptuStream, so I tried that and It works: out.write(6); Thank you for the guidance!! On Fri, Aug 8, 2008 at 7:31 PM, Agustin Mu?oz wrote: > Hi Florian, thanks for the answer. By send(6) you mean to get the port > OutputStream and write a 6? > > I try that but it didn't work. > > Any suggestion? > > Thanks > > > On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < > florianmanschwetus at gmx.de> wrote: > >> Agustin Mu?oz schrieb: >> >> Hi, I'm still learning about serial communication and I have some doubts. >>> I've got this question about how to do the following thing in rxtx. >>> I have this hardware that connect to a PC using a serial port. These >>> hardware receives data from a telephone line, proccess it, and then send it >>> forward to the serial port. I've used a program named wincomm that shows >>> what information is send it through the serial port and I have the nex >>> behaviour: >>> >>> The hardware has a buffer where all data is stored, that cannot be sent >>> it through the seria port. >>> The program reads the first data send it by the hardware, and keep >>> reading the same data always. >>> There is a button in the application that says enable Ack, and when I >>> click, then the hardware start to send all the stored information, and all >>> the information is shown. >>> >>> I write a class, using rxtx that reads the serial port, and the same >>> thing happens, it remains reading the same (first) data all the time. And I >>> thing something like the enable Ack I'm missing. >>> How can I do this enable Ack from my java code using rxtx? >>> >> Afaik, a look at man ascii reveals: >> Okt Dez Hex Char >> 006 6 06 ACK >> So, i hope this will do the job: >> send(6); >> >> florian >> >>> >>> Thanks in advance >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/b918ab3d/attachment-0002.html From florianmanschwetus at gmx.de Sat Aug 9 00:45:43 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Sat, 09 Aug 2008 08:45:43 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4899667C.6010706@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> Message-ID: <489D3D17.9090209@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >> Florian Manschwetus wrote: >>> Ok, sounds fine for the receiving problem. >>> But why i have to wait after each byte when sending a command squence? >>> (the for loop in send command) >> >> Hi Florian, >> I'd imagine you probably don't! You could send all bytes in one go and >> RXTX would send them. The problem is most probably the other end: >> perhaps it has a really small buffer, some non-standard UART, or a >> crazy timing issue. If you attach a terminal to your output and send >> all the bytes of a command in one go they should appear no problem. >> >> Regards, >> Michael Erskine. >> > correct with a terminal on the other end it works, my idea was that this > basic baud has some influence. Could some one explain what it is for? > > Florian To make it more clear, my problem is that i can't use: outputStream.write(byte[]); => Beamer doesn't understand the sequence. (mostly no answer when he answers then *001) when i use this construct instead: for (int i = 0; i < command.length; i++) { this.outputStream.write(command[i]); try { Thread.sleep(25); } catch (InterruptedException e) { // TODO Auto-generated catch block e.printStackTrace(); } } it works nearly reliable. So what could it be? This Basic Baud is what exactly? Florian -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080809/692304ee/attachment-0002.bin From tjarvi at qbang.org Sat Aug 9 16:37:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Aug 2008 16:37:19 -0600 (MDT) Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489D3D17.9090209@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> <489D3D17.9090209@gmx.de> Message-ID: On Sat, 9 Aug 2008, Florian Manschwetus wrote: > Florian Manschwetus schrieb: >> Michael Erskine schrieb: >>> Florian Manschwetus wrote: >>>> Ok, sounds fine for the receiving problem. >>>> But why i have to wait after each byte when sending a command squence? >>>> (the for loop in send command) >>> >>> Hi Florian, >>> I'd imagine you probably don't! You could send all bytes in one go and >>> RXTX would send them. The problem is most probably the other end: perhaps >>> it has a really small buffer, some non-standard UART, or a crazy timing >>> issue. If you attach a terminal to your output and send all the bytes of a >>> command in one go they should appear no problem. >>> >>> Regards, >>> Michael Erskine. >>> >> correct with a terminal on the other end it works, my idea was that this >> basic baud has some influence. Could some one explain what it is for? >> >> Florian > To make it more clear, > my problem is that i can't use: > outputStream.write(byte[]); > => Beamer doesn't understand the sequence. (mostly no answer when he answers > then *001) > > when i use this construct instead: > > for (int i = 0; i < command.length; i++) { > this.outputStream.write(command[i]); > try { > Thread.sleep(25); > } catch (InterruptedException e) { > // TODO Auto-generated catch block > e.printStackTrace(); > } > } > > it works nearly reliable. > > So what could it be? This Basic Baud is what exactly? > I suspect you are using the 'moon protocol' and don't know it. RXTX enables this by default. The buffer on the other end is first in first out while reading. If the buffer is full, the bits are hand carried to the moon and burried. Then if the other side reads a couple bytes, two more bytes go into the buffer followed by more moon protocol. The resulting array of bytes the other side reads may appear to be scrambled until you go to the moon, get the bits and insert them in the right place. Flow control can prevent the default moon protocol and throttles the communiation by almost writing a byte at a time as need be. Hardware flow control is preferable but software flow control should also work. Read and write can appear to hang if the other side is not connected. This is why we don't enable them all the time. If you can't use flow control, you have to take care with the moon protocol and give the other side time to read. That is what your slower version of write is doing. -- Trent Jarvi tjarvi at qbang.org From rick_knight at rlknight.com Mon Aug 4 13:25:10 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Mon, 04 Aug 2008 12:25:10 -0700 Subject: [Rxtx] Sun's Comm API? Message-ID: <48975796.4010600@rlknight.com> I have an application that requires the javax compatible version of RXTX and Sun's comm api. I've been able to download and extract the version of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api anywhere. Can someone tell me where I can find it? Or maybe send me a copy? Also, when I try to build RXTX, configure and make complete successfully but make install failes with this error libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 I've never come accross this error before. How can I get past it? Thanks, Rick From bboyes at systronix.com Mon Aug 4 19:10:01 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:10:01 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48975796.4010600@rlknight.com> References: <48975796.4010600@rlknight.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/cb9c6167/attachment-0007.html From bboyes at systronix.com Mon Aug 4 19:12:37 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:12:37 -0600 Subject: [Rxtx] Towards an RXTX release - CSR BT/USB chipset In-Reply-To: <488FB7E7.8000802@gmail.com> References: <460801A4097E3D4CA04CC64EE648584806C56CF0@ism-mail03.corp.ad.wrs.com> <13557-75390@sneakemail.com> <20980-23424@sneakemail.com> <488FB7E7.8000802@gmail.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/52236088/attachment-0007.html From tjarvi at qbang.org Mon Aug 4 19:42:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 19:42:21 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: On Mon, 4 Aug 2008, Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: > I have an application that requires the javax compatible > version of RXTX > and Sun's comm api. I've been able to download and extract > the version > of RXTX that I need (2.0-7pre2) but I can't find Sun's camm > api > anywhere. Can someone tell me where I can find it? Or maybe > send me a > > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm port > support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have just > a ZIP with only the .class JAR file - no source or docs), has a readme > with these comments: > > This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release.? The 2.0.3 release itself is > no longer distributed.? comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project.? The RxTx project (http://www.rxtx.org ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org) was opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support.? Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins.? Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > ? > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > I hope that is helpful! > It would be nice to work with Sun to resolve those longstanding issues. But it may not be practical unless the process goes as fast and painless as the grandfathering of commapi did. Another option may be the old kaffe extensions that moved to gnu classpathx. These don't have the native libraries but should provide the 2.0 interface and the javax.comm.properties mechansim for SPI. http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Mon Aug 4 20:23:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Mon, 04 Aug 2008 20:23:57 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4897B9BD.5070809@ergotech.com> Has there been any work/would it be possible, to layer a javacomm look-alike on top of the GNU code? The goal is not to move the javax code forward, but to emulate the "legacy" javax packages for people who still need this. Jim Trent Jarvi wrote: > On Mon, 4 Aug 2008, Bruce Boyes wrote: > >> At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible >> version of RXTX >> and Sun's comm api. I've been able to download and extract >> the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm >> api >> anywhere. Can someone tell me where I can find it? Or maybe >> send me a >> >> >> javaxcomm has had a sort of on-again off-again history. The windoze >> version has been languishing for years (literally) but there are newer >> versions for other OS's. >> >> We try to keep links on one of our help pages current: >> http://www.practicalembeddedjava.com/tools/javatools_list.html >> which gets you to here: >> http://java.sun.com/products/javacomm/ >> where it says in fact they no longer even support Windows and Mac: >> "Implementations of the API are currently available for Solaris SPARC, >> Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so >> someone could support it. But I guess that's part of the reason RXTX >> exists! >> >> So one of Sun's own products, SunSPOT, has to use RXTX to get comm port >> support. >> >> The version we use is 2.0 from 11/15/1998. I have posted it on our >> website, which is within the terms of the license agreement contained >> therein (as I understand it). >> >> The last version of javaxcomm for Windows, 2.0.3, (for which I have just >> a ZIP with only the .class JAR file - no source or docs), has a readme >> with these comments: >> >> This distribution contains the comm.jar file original part >> of the COMMAPI 2.0.3 release. The 2.0.3 release itself is >> no longer distributed. comm.jar, which contains the comm >> API java class files (eg. Sun's binary implementation of the >> interface classes), is being made available, unsupported, >> with no obligation to fix bugs, at the request of the RXTX >> project. The RxTx project (http://www.rxtx.org ), uses the >> comm.jar class files, but provides their own native library >> components to provide support for other platforms. >> >> The 2.0.3 comm.jar is being provided in this way because >> as of COMMAPI 3.x, the java binary implementation forked and >> became incompatible with the RxTx project's native code. >> Due to the lack of a clear business case, and to resource >> constraints, no additional resources are being >> provided to provide an alternative engineering solution >> at the time of writing. >> >> RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: >> >> Ultimately the COMMAPI would be better served if a Java >> Community Process JSR (http://www.jcp.org) was opened and >> the COMMAPI was rearchitected to provide a more pluggable >> framework to improve cross-platform support. Such an >> architecture would embody a better defined and better >> documented SPI interface, including a way for comm. ports >> to be revealed to the client application through the API >> via platform-aware plugins. Similarly, native code used >> to access comm port in general could be handled more >> flexibly using a plugin model, whereby on any platform, >> multiple native modules could be in use simultaneously. >> >> Since there are now various ways serial ports can be implemented >> and accessed, modular comm. port JNI native libraries would be >> of benefit insofar as removing the burden of over-generalization >> from any single native component, or inversely, by relieving the >> implicit constraint that comm. drivers be accessed only via a >> monolithic mechanism, such as the UNIX vnode interface. >> >> paul.klissner at sun.com >> 6/10/06 >> >> I hope that is helpful! >> > > It would be nice to work with Sun to resolve those longstanding issues. > But it may not be practical unless the process goes as fast and painless > as the grandfathering of commapi did. > > Another option may be the old kaffe extensions that moved to gnu > classpathx. These don't have the native libraries but should provide > the 2.0 interface and the javax.comm.properties mechansim for SPI. > > http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Mon Aug 4 21:09:15 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 21:09:15 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? Message-ID: Hi Jim, I will not step into the javax.comm namespace without Sun's explicite permission. I fully understand the pain point you are trying to address. In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm Linux) - which remains an integral part of rxtx. At the time it was a win for Sun and rxtx. The Sun commapi license is/was fairly clear that rxtx should not step into that namespace. It made sense as Sun was active in that space and rxtx may go into another namespace - it was an experiment in working with Sun. This may sound silly looking at something that happened almost 10 years ago. In a community of respect which Sun helped create, there is no question about what to do. I hope eventually Sun will step up and do a right thing too. I agree that this is hurting the API more than helping it. There are also questions about how to replace the API in the long term which includes HID support which isn't going well so far. Others that can't even look at Sun's javax.comm today and can look at Kaffe's contribution to classpathx can easily work around such restrictions. On Mon, 4 Aug 2008, Jim Redman wrote: > Has there been any work/would it be possible, to layer a javacomm > look-alike on top of the GNU code? > > The goal is not to move the javax code forward, but to emulate the > "legacy" javax packages for people who still need this. > > Jim > > Trent Jarvi wrote: >> >> It would be nice to work with Sun to resolve those longstanding issues. >> But it may not be practical unless the process goes as fast and painless >> as the grandfathering of commapi did. >> >> Another option may be the old kaffe extensions that moved to gnu >> classpathx. These don't have the native libraries but should provide >> the 2.0 interface and the javax.comm.properties mechansim for SPI. >> >> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From florianmanschwetus at gmx.de Tue Aug 5 05:04:46 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 13:04:46 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: References: <48971C1F.9020806@gmx.de> Message-ID: <489833CE.1040801@gmx.de> Just look at sendCommand in this method I have to place a Thread.sleep(20) after each byte send to get working. Even the event based receive doesn't work fine but this could be may stupidness. The specifikation document (it is on the last pages of the manual) for the beamer could be found on: http://www.optoma.co.uk/support.aspx Florian Manschwetus Trent Jarvi schrieb: > > Hi Florian > > Sorry for the top post in advance. I worry you may not see my answer > under all your code :) > > I have not received this email before. This is 500k of code which I > don't have time to read. I can spend about 5 min on each hobby email > and still get to work in the morning. I have a couple suggestions for > how to get an answer. > > First, cut out your comments and extra code so you can demonstrate the > question (I might even glance and see what is wrong then). Don't go for > a working final product. Isolate the problem using a simple program and > then ask with that as an example. If I did what you just did, I'd have > to post 3/4 of a million lines of code :) > > Second, join the rxtx mail-list and ask there. This will give you 100x > more eyes. I'll also read and try to follow. > > -- > taj > > > > On Mon, 4 Aug 2008, Florian Manschwetus wrote: > >> It could be that my university account is blocked by filters so >> resending from here. >> >> >> Topic is to control Optoma HD80 beamer using rs232 serial chat. >> This code is able to detect power state and switch the beamer on / off. >> connected is the beamer using a digitus usb 2.0 serial adapter with an >> FT232 USB-Serial adapter the systems architecture is amd64. >> >> Please take a look in the sendCommand routine i have to place theire >> those Thread.sleep to get it working. >> Now the question is this correct or is there a better way to get this >> working correctly? >> >> In the javadoc coming with the install i found this: >> setBaudBase >> >> public boolean setBaudBase(int BaudBase) >> throws UnsupportedCommOperationException, >> java.io.IOException >> >> Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 >> before using. >> >> could this explain the error? >> I attached my java source and the protocol description for the beamer >> (available on vendor website). >> >> thx, >> Florian Manschwetus >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: TestRS232.java Type: text/x-java Size: 9143 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0014.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0015.bin From michael.erskine at ketech.com Tue Aug 5 05:53:49 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Tue, 5 Aug 2008 12:53:49 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489833CE.1040801@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> > Just look at sendCommand in this method I have to place a > Thread.sleep(20) after each byte send to get working. Even the event > based receive doesn't work fine but this could be may stupidness. Hi Florian, Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. Regards, Michael Erskine. From florianmanschwetus at gmx.de Tue Aug 5 07:28:15 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:28:15 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> Message-ID: <4898556F.8000208@gmx.de> Michael Erskine schrieb: >> Just look at sendCommand in this method I have to place a >> Thread.sleep(20) after each byte send to get working. Even the event >> based receive doesn't work fine but this could be may stupidness. > > Hi Florian, > > Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. > > Regards, > Michael Erskine. > Ok, sounds fine for the receiving problem. But why i have to wait after each byte when sending a command squence? (the for loop in send command) Florian > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/284f350c/attachment-0006.bin From florianmanschwetus at gmx.de Tue Aug 5 07:44:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:44:14 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <4898592E.2020908@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >>> Just look at sendCommand in this method I have to place a >>> Thread.sleep(20) after each byte send to get working. Even the event >>> based receive doesn't work fine but this could be may stupidness. >> >> Hi Florian, >> >> Yes, naturally you'll have to wait for a response from the other end. >> Why not wait for notification from the event thread perhaps using a >> BlockingDeque rather than your LinkedList. Generally I >> try to decouple all input and output streams: in your case your >> application is operating synchronously like the "expect" program >> (http://expect.nist.gov/) so waits (or timeouts) will need to be >> factored in. >> >> Regards, >> Michael Erskine. >> > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) > > Florian Furthermore there is this basic baud with this confusing javadoc entry: public boolean setBaudBase(int BaudBase) throws UnsupportedCommOperationException, java.io.IOException Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 before using. maybe this could explain something Florian >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/006c7425/attachment-0006.bin From jredman at ergotech.com Tue Aug 5 09:13:36 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 05 Aug 2008 09:13:36 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: Message-ID: <48986E20.3060104@ergotech.com> Trent, So two issues: 1) Technically I'm still not sure how easy/practical a layer would be. The problems are always classes like listeners, and wrapping returns of gnu.io classes. I really see it as a "delegate" type of concept. Any thoughts or ideas of the practicality of this approach? The idea is not to modify RXTX. 2) Javax. The javax namespace does seem to be in widespread use outside of Sun (the same is true for the java namespace). The classpath extensions, or some other location, should be interested in a JavaComm implementation even if it does have dependencies on RXTX. Would you have any philosophical objection to an approach like that? Of course, I suspect it might be better if someone with that authority at Sun would admit that the javax namespace is already in the wild and that there is no problem with it being used within RXTX. Jim Trent Jarvi wrote: > Hi Jim, > > I will not step into the javax.comm namespace without Sun's explicite > permission. I fully understand the pain point you are trying to address. > > In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm > Linux) - which remains an integral part of rxtx. At the time it was a win for > Sun and rxtx. > > The Sun commapi license is/was fairly clear that rxtx should not step into that > namespace. It made sense as Sun was active in that space and rxtx may go into > another namespace - it was an experiment in working with Sun. > > This may sound silly looking at something that happened almost 10 years ago. > In a community of respect which Sun helped create, there is no question about > what to do. I hope eventually Sun will step up and do a right thing too. > > I agree that this is hurting the API more than helping it. There are also > questions about how to replace the API in the long term which includes HID > support which isn't going well so far. > > Others that can't even look at Sun's javax.comm today and can look at Kaffe's > contribution to classpathx can easily work around such restrictions. > > On Mon, 4 Aug 2008, Jim Redman wrote: > >> Has there been any work/would it be possible, to layer a javacomm >> look-alike on top of the GNU code? >> >> The goal is not to move the javax code forward, but to emulate the >> "legacy" javax packages for people who still need this. >> >> Jim >> >> Trent Jarvi wrote: >>> It would be nice to work with Sun to resolve those longstanding issues. >>> But it may not be practical unless the process goes as fast and painless >>> as the grandfathering of commapi did. >>> >>> Another option may be the old kaffe extensions that moved to gnu >>> classpathx. These don't have the native libraries but should provide >>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>> >>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From sandeep at genevasoftech.com Tue Aug 5 11:18:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Tue, 05 Aug 2008 22:48:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <48988B6C.5080409@genevasoftech.com> Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. *-- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/ad20f1cb/attachment-0006.html From Martin.Oberhuber at windriver.com Tue Aug 5 13:30:17 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Tue, 5 Aug 2008 21:30:17 +0200 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Sandeep, shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on Sol7 but I've successfully run it on Sol9 and Sol10. Or is your request really about a native 64bit variant? I'm afraid that then you're out of luck since I think that quite a bit of RXTX is not yet ready for 64 bit. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Sandeep Kumar K Sent: Tuesday, August 05, 2008 7:19 PM To: rxtx at qbang.org Subject: [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so for Solaris 9 Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. -- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/81b7f988/attachment-0006.html From tjarvi at qbang.org Tue Aug 5 22:38:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 22:38:34 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 5 Aug 2008, Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built > on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid that > then > you're out of luck since I think that quite a bit of RXTX is not yet > ready > for 64 bit. > While rxtx-2.1-7 probably has problems, The CVS code should be OK for 64 bit Solaris. If it isn't, let me know and I'll find which patch is missing. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Aug 5 23:13:00 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 23:13:00 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48986E20.3060104@ergotech.com> References: <48986E20.3060104@ergotech.com> Message-ID: On Tue, 5 Aug 2008, Jim Redman wrote: > Trent, > > So two issues: > > 1) Technically I'm still not sure how easy/practical a layer would be. The > problems are always classes like listeners, and wrapping returns of gnu.io > classes. I really see it as a "delegate" type of concept. Any thoughts or > ideas of the practicality of this approach? The idea is not to modify RXTX. I have not put too much thought into this. I assume you want what rxtx 2.0 provided to tie into javax.comm implementations. More classes could be added to rxtx 2.1-7 for SPI support. Maintaining rxtx-2.0 could also be handed to someone if they like. > > 2) Javax. The javax namespace does seem to be in widespread use outside of > Sun (the same is true for the java namespace). The classpath extensions, or > some other location, should be interested in a JavaComm implementation even > if it does have dependencies on RXTX. Would you have any philosophical > objection to an approach like that? > No problems. Classpathx would be a possible place to do it. I'd suggest thinking twice about what this involves in practical terms. You would be wanting to revive the 2.0 API while Sun is at 3.0 and grandfathering the JSR. This undermines the main reason (established api) for using the javax.comm namespace and does not leave such a project in a good position. The only win I see here is maintaining support for applications that can't migrate namespaces. Not that that isn't important. At some point it is going to be less work to just edit the bytecode :) Such a javax.comm effort would also be signing up new projects that decided to use the work up for concerns they probably will not understand or expect. That probably isn't a good path to facilitate for new projects at this time. We will put a good faith effort to work well with others but keep in mind the project has limited bandwidth for such efforts. > Of course, I suspect it might be better if someone with that authority at Sun > would admit that the javax namespace is already in the wild and that there is > no problem with it being used within RXTX. > > Jim > > Trent Jarvi wrote: >> Hi Jim, >> >> I will not step into the javax.comm namespace without Sun's explicite >> permission. I fully understand the pain point you are trying to address. >> >> In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java >> Comm Linux) - which remains an integral part of rxtx. At the time it was a >> win for Sun and rxtx. >> >> The Sun commapi license is/was fairly clear that rxtx should not step into >> that namespace. It made sense as Sun was active in that space and rxtx may >> go into another namespace - it was an experiment in working with Sun. >> >> This may sound silly looking at something that happened almost 10 years >> ago. In a community of respect which Sun helped create, there is no >> question about what to do. I hope eventually Sun will step up and do a >> right thing too. >> >> I agree that this is hurting the API more than helping it. There are also >> questions about how to replace the API in the long term which includes HID >> support which isn't going well so far. >> >> Others that can't even look at Sun's javax.comm today and can look at >> Kaffe's contribution to classpathx can easily work around such >> restrictions. >> >> On Mon, 4 Aug 2008, Jim Redman wrote: >> >>> Has there been any work/would it be possible, to layer a javacomm >>> look-alike on top of the GNU code? >>> >>> The goal is not to move the javax code forward, but to emulate the >>> "legacy" javax packages for people who still need this. >>> >>> Jim >>> >>> Trent Jarvi wrote: >>>> It would be nice to work with Sun to resolve those longstanding issues. >>>> But it may not be practical unless the process goes as fast and painless >>>> as the grandfathering of commapi did. >>>> >>>> Another option may be the old kaffe extensions that moved to gnu >>>> classpathx. These don't have the native libraries but should provide >>>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>>> >>>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From sandeep at genevasoftech.com Wed Aug 6 00:03:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Wed, 06 Aug 2008 11:33:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: <48993EB8.30107@genevasoftech.com> Thank you Mr. Martin for your suggestion. The native file which is given in rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am getting the following error . Any suggestions to solve this issue. I am using Solaris SPARC 64 bit machine. ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) thrown while loading gnu.io.RXTXCommDriver Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(Unknown Source) at java.lang.ClassLoader.loadLibrary(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) at com.ReadFromModem.main(ReadFromModem.java:84) * * *Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid > that then > you're out of luck since I think that quite a bit of RXTX is not yet ready > for 64 bit. > > Cheers, > -- > *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > ------------------------------------------------------------------------ > *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On > Behalf Of *Sandeep Kumar K > *Sent:* Tuesday, August 05, 2008 7:19 PM > *To:* rxtx at qbang.org > *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so > for Solaris 9 > > Hi, > > Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 > bit machine. The librxtxSerial.so given in website is for Solaris 8. > > *-- > > Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/1e920343/attachment-0006.html From tjarvi at qbang.org Wed Aug 6 00:21:42 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 00:21:42 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <48993EB8.30107@genevasoftech.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> <48993EB8.30107@genevasoftech.com> Message-ID: Hi Sandeep You may be out of luck unless you can compile the 2.1 src in CVS (requires gnu make and gcc). But you could try the ToyBox(R)(TM) which is a collection of WiLdLy untested cross compiled 2.1-7 binaries covering everything from the ibm z series to embeded arm/ppc. To give an idea how poorly these are tested, I don't even know if z series machines have a serial port. ftp://www.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Solaris They should at least match the binary types. Actually, I think if you use the rxtx jar from CVS with that file, it should 'work' as the fix for 64 bits was in java not the native code. You could just cd rxtx*/src; javac *.java then jar -cf RXTXcomm.jar `find -name \*.class` to create the hybrid which will complain about version information a bit. On Wed, 6 Aug 2008, Sandeep Kumar K wrote: > Thank you Mr. Martin for your suggestion. The native file which is given in > rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am > getting the following error . > Any suggestions to solve this issue. > I am using Solaris SPARC 64 bit machine. > > ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar > java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 > (Possible cause: architecture word > width mismatch) thrown while loading gnu.io.RXTXCommDriver > Exception in thread "main" java.lang.UnsatisfiedLinkError: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF > class: ELFCLASS64 (Possible cause: > architecture word width mismatch) > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(Unknown Source) > at java.lang.ClassLoader.loadLibrary(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > at com.ReadFromModem.main(ReadFromModem.java:84) > > * > * > > *Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > > > Oberhuber, Martin wrote: >> Sandeep, >> shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse >> variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on >> Sol7 but I've successfully run it on Sol9 and Sol10. >> Or is your request really about a native 64bit variant? I'm afraid that >> then >> you're out of luck since I think that quite a bit of RXTX is not yet ready >> for 64 bit. >> Cheers, >> -- >> *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> ------------------------------------------------------------------------ >> *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On >> Behalf Of *Sandeep Kumar K >> *Sent:* Tuesday, August 05, 2008 7:19 PM >> *To:* rxtx at qbang.org >> *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so >> for Solaris 9 >> >> Hi, >> >> Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 >> bit machine. The librxtxSerial.so given in website is for Solaris 8. >> >> *-- >> Thanks & Regards >> >> Sandeep Kumar K >> Sr. Software Engineer >> Geneva Software Technologies >> Whitefield, Bangalore >> Mob : 9880193454* >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> From michael.erskine at ketech.com Wed Aug 6 01:39:28 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 6 Aug 2008 08:39:28 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Florian Manschwetus wrote: > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) Hi Florian, I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. Regards, Michael Erskine. From florianmanschwetus at gmx.de Wed Aug 6 02:53:16 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 06 Aug 2008 10:53:16 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Message-ID: <4899667C.6010706@gmx.de> Michael Erskine schrieb: > Florian Manschwetus wrote: >> Ok, sounds fine for the receiving problem. >> But why i have to wait after each byte when sending a command squence? >> (the for loop in send command) > > Hi Florian, > I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. > > Regards, > Michael Erskine. > correct with a terminal on the other end it works, my idea was that this basic baud has some influence. Could some one explain what it is for? Florian > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/c2b4fa84/attachment-0006.bin From rick_knight at rlknight.com Wed Aug 6 13:01:07 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:01:07 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F4F3.3020707@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > I have an application (Readerware) that uses RXTX with Javax to access the serial port. This used to work fine under previous Linux' and Java, but something has changed, I assume with Java itself , that is causing the application to fail with a link error. The application is not able to find librxtxSerialParallel.so. RXTX supplies librxtxSerial.so and librxtxParallel.so, but not librxtxSerialParallel.so. Where can I get librxtxSerialParallel.so, or do I need it? Is something else causing the lib to not be found? Thanks, Rick Knight From rick_knight at rlknight.com Wed Aug 6 13:17:55 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:17:55 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F8E3.5060400@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Thanks for the reply. The developer of the app I'm trying to use (Readerware) has sent me a copy of the comm.api and I've copied the library (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar into the proper places. When I try to run the application, I get this error... Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: /usr/lib/libSolarisSerialParallel.so: /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not little-endian (Possible cause: endianness mismatch) Caught java.lang.UnsatisfiedLinkError: com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I while loading driver com.sun.comm.SolarisDriver Is there a way around this error? Thanks again, Rick Knight From jlar310 at gmail.com Wed Aug 6 13:37:42 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 14:37:42 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899F8E3.5060400@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > The developer of the app I'm trying to use (Readerware) has sent me a > copy of the comm.api and I've copied the library > (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar > into the proper places. When I try to run the application, I get this > error... > > Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: > /usr/lib/libSolarisSerialParallel.so: > /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not > little-endian (Possible cause: endianness mismatch) > Caught java.lang.UnsatisfiedLinkError: > com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I > > while loading driver com.sun.comm.SolarisDriver > > Is there a way around this error? What host OS are you running? From your original post it looks like 32 bit Linux. The libSolarisSerialParallel.so file is for Sun Solaris and will vary depending on the underlying hardware architecture as well. Sorry for the double post Rick, but I failed to send this to the list the first time... -- Jeff From rick_knight at rlknight.com Wed Aug 6 13:44:29 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:44:29 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: <4899FF1D.9030504@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > > >> The developer of the app I'm trying to use (Readerware) has sent me a >> copy of the comm.api and I've copied the library >> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >> into the proper places. When I try to run the application, I get this >> error... >> >> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >> /usr/lib/libSolarisSerialParallel.so: >> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >> little-endian (Possible cause: endianness mismatch) >> Caught java.lang.UnsatisfiedLinkError: >> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >> >> while loading driver com.sun.comm.SolarisDriver >> >> Is there a way around this error? >> > > What host OS are you running? From your original post it looks like 32 > bit Linux. > > The libSolarisSerialParallel.so file is for Sun Solaris and will vary > depending on the underlying hardware architecture as well. > > I'm running Kubuntu Linux (debian based). It's 32 bit. Rick Knight From jlar310 at gmail.com Wed Aug 6 15:33:23 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 16:33:23 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > I don't think Sun did binary libraries for Linux in the 2.0 version. Can someone with more historical experience than I confirm that? I recently tried to port a Comm API application from Solaris sparc to Linux x86 and likewise could not get my hands on the binary libraries. I eventually just re-wrote the code to use the gnu namespace packages and rxtx 2.1. What I don't understand is why your application vendor does not provide everything you need to run their software. FYI: I have librxtxParallel.so and librxtxSerial.so installed at JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is /usr/java/default which is actually a softlink to /usr/java/jre1.6.0_05. -- Jeff From defiantlew at yahoo.com.au Wed Aug 6 16:29:33 2008 From: defiantlew at yahoo.com.au (Lew L) Date: Thu, 7 Aug 2008 08:29:33 +1000 Subject: [Rxtx] Sun's Comm API Documentation References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> Message-ID: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> As a matter of interest is the Sun Comm API documentation available somewhere? I have tried the Sun site but it seems to have been removed. Unless I have missed the documentation for RXTX? I javadocced the RXTX source but information (to me) is minimal. Somewhere I got the impression that the Sun Comm API docs is, or was, compatible with RXTX, what is the best docs to use in conjuntion with RXTX and where may the be available? Cheers Lew From rick_knight at rlknight.com Wed Aug 6 17:18:33 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:18:33 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A3149.4050306@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff I'm not sure if I posted this here or not, but when I try to build RXTX from source I get this install error... make all-am make[1]: Entering directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' make[1]: Nothing to be done for `all-am'. make[1]: Leaving directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 Can you tell me how to get past this error and get RXTX built and installed? Thanks, Rick From bboyes at systronix.com Wed Aug 6 17:40:12 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Wed, 06 Aug 2008 17:40:12 -0600 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: At 16:29 08/06/2008, Lew L wrote: >As a matter of interest is the Sun Comm API documentation available >somewhere? I have tried the Sun site but it seems to have been removed. It's in the file we have posted, link in prev email (sorry, in a huge hurry right now). Javadocs definitely there. >Unless I have missed the documentation for RXTX? I javadocced the RXTX >source but information (to me) is minimal. >Somewhere I got the impression that the Sun Comm API docs is, or was, >compatible with RXTX, what is the best docs to use in conjuntion with RXTX >and where may the be available? Yeah, this is one of my concerns/beefs. There is little documentation for RXTX and it isn't just the same as javaxcomm. I would be willing to help out writing docs for RXTX! Yes really... esp if we can fix the Bluetooth issues. best regards Bruce >Cheers >Lew > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx ------- WWW.SYSTRONIX.COM ---------- Real embedded Java and much more +1-801-534-1017 Salt Lake City, USA From rick_knight at rlknight.com Wed Aug 6 17:54:08 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:54:08 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A39A0.2090309@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff, I would like for my vendor to switch to rxtx 2.1. It would make things much easier for me. I'm not sure why he's still using the javax compatible code. He's a small operation. Re-writing the code to use gnu namespace sounds like a major overhaul. Was it? Thanks, Rick From tjarvi at qbang.org Wed Aug 6 21:35:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:35:12 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: >> >>> Jeff wrote: >>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>>> >>>> >>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things > much easier for me. I'm not sure why he's still using the javax > compatible code. He's a small operation. Re-writing the code to use gnu > namespace sounds like a major overhaul. Was it? > Hi Jeff, The changes are fairly mechanical. Imports need to change and any explicite use of the namespace needs to change such as catching an exception. The following script was made for maintaining rxtx 2.0 but can apply to other needs. It is in the contrib dir with rxtx source. #!/bin/sh # Don't use! :) # # Sat, 03 May 2003 16:45:08 Modifications from J?rg Weule # Create a ed-cmd for the change of one pattern # case $1 in gnu) X=g/javax_comm/s+javax_comm+gnu_io+g ;; javax) X=g/gnu_io/s+gnu_io+javax_comm+g ;; *) echo;echo;echo From the top rxtx directory run;echo;echo -e \\t./ChangePackage.sh gnu;echo -e \\t\\tor;echo -e \\t./ChangePackage.sh javax;echo;echo; exit 0 ;; esac # # ed will be used to keep the owner and mode of the files unchanged. # We have run the ed-script for the characters '.' '/' as well. # "tr _ $D" do the change. # find . -type f -a -print | grep -v $0 | (while read F ; do ( echo $X; echo $X| tr _ /; echo $X| tr _ .; echo w; echo q ) | ed $F 2>&1 >/dev/null done ) # # Now we do little changes at the Makefiles. Hope that all we need. # find . -name Makefile\* -a -print | (while read F ; do cat < References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: On Thu, 7 Aug 2008, Lew L wrote: > As a matter of interest is the Sun Comm API documentation available > somewhere? I have tried the Sun site but it seems to have been removed. > > Unless I have missed the documentation for RXTX? I javadocced the RXTX > source but information (to me) is minimal. > Somewhere I got the impression that the Sun Comm API docs is, or was, > compatible with RXTX, what is the best docs to use in conjuntion with RXTX > and where may the be available? > Hi Lew, The documentation on Sun's website is accurate. The changes that are problematic in 3.0 are on the backside which rxtx used to plug into. http://java.sun.com/products/javacomm/reference/api/index.html CommPortIdentifier may have some minor differences (judging by the authors notes). -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Aug 6 21:46:08 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:46:08 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > If javax.comm.properties is properly installed and you are using a 2.0 version of Sun's commapi with rxtx 2.0, you should not see the library attempt to load libSolarisSerialParallel.so. Sun CommAPI 3.0 will not work with any version of rxtx as it is hard coded to use the shared library. See the INSTALL file with rxtx-2.0 source for more help with the properties file. -- Trent Jarvi tjarvi at qbang.org From jlar310 at gmail.com Thu Aug 7 06:32:06 2008 From: jlar310 at gmail.com (Jeff) Date: Thu, 7 Aug 2008 07:32:06 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > Jeff wrote: >> >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >> wrote: >> >>> >>> Jeff wrote: >>> >>>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>> wrote: >>>> >>>> >>>> >>>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things much > easier for me. I'm not sure why he's still using the javax compatible code. > He's a small operation. Re-writing the code to use gnu namespace sounds like > a major overhaul. Was it? I found it quite easy. In fact, in order to accommodate the transition, I actually separated all of the code that deals directly with the Comm API or RXTX into a helper class. The helper class was then coded to use reflection to determine which library was available and then instantiate the necessary objects. No direct imports of either library are used. The main application just needs to get it's hands on the IO streams and need not deal directly with the libraries. Other programs may not be so simple... But this doesn't really help you unless your vendor forks over the source code... -- Jeff From rick_knight at rlknight.com Thu Aug 7 09:47:12 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Thu, 07 Aug 2008 08:47:12 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: <489B1900.10108@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >>> wrote: >>> >>> >>>> Jeff wrote: >>>> >>>> >>>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>>> copy of the comm.api and I've copied the library >>>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>>> into the proper places. When I try to run the application, I get this >>>>>> error... >>>>>> >>>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>>> /usr/lib/libSolarisSerialParallel.so: >>>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>>> little-endian (Possible cause: endianness mismatch) >>>>>> Caught java.lang.UnsatisfiedLinkError: >>>>>> >>>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>>> >>>>>> while loading driver com.sun.comm.SolarisDriver >>>>>> >>>>>> Is there a way around this error? >>>>>> >>>>>> >>>>>> >>>>> What host OS are you running? From your original post it looks like 32 >>>>> bit Linux. >>>>> >>>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>>> depending on the underlying hardware architecture as well. >>>>> >>>>> >>>>> >>>>> >>>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>>> >>>> >>>> >>> I don't think Sun did binary libraries for Linux in the 2.0 version. >>> Can someone with more historical experience than I confirm that? >>> >>> I recently tried to port a Comm API application from Solaris sparc to >>> Linux x86 and likewise could not get my hands on the binary libraries. >>> I eventually just re-wrote the code to use the gnu namespace packages >>> and rxtx 2.1. >>> >>> What I don't understand is why your application vendor does not >>> provide everything you need to run their software. >>> >>> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >>> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >>> /usr/java/default which is actually a softlink to >>> /usr/java/jre1.6.0_05. >>> >>> >>> >> Jeff, >> >> I would like for my vendor to switch to rxtx 2.1. It would make things much >> easier for me. I'm not sure why he's still using the javax compatible code. >> He's a small operation. Re-writing the code to use gnu namespace sounds like >> a major overhaul. Was it? >> > > I found it quite easy. In fact, in order to accommodate the > transition, I actually separated all of the code that deals directly > with the Comm API or RXTX into a helper class. The helper class was > then coded to use reflection to determine which library was available > and then instantiate the necessary objects. No direct imports of > either library are used. The main application just needs to get it's > hands on the IO streams and need not deal directly with the libraries. > Other programs may not be so simple... > > But this doesn't really help you unless your vendor forks over the > source code... > > Jeff, This may not help me directly, but I'm going to forward this thread to the vendor. I think he'll be open to making things work. Thanks again, Rick Knight From agusmunioz at gmail.com Thu Aug 7 16:39:51 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Thu, 7 Aug 2008 19:39:51 -0300 Subject: [Rxtx] How to send ack? Message-ID: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Hi, I'm still learning about serial communication and I have some doubts. I've got this question about how to do the following thing in rxtx. I have this hardware that connect to a PC using a serial port. These hardware receives data from a telephone line, proccess it, and then send it forward to the serial port. I've used a program named wincomm that shows what information is send it through the serial port and I have the nex behaviour: The hardware has a buffer where all data is stored, that cannot be sent it through the seria port. The program reads the first data send it by the hardware, and keep reading the same data always. There is a button in the application that says enable Ack, and when I click, then the hardware start to send all the stored information, and all the information is shown. I write a class, using rxtx that reads the serial port, and the same thing happens, it remains reading the same (first) data all the time. And I thing something like the enable Ack I'm missing. How can I do this enable Ack from my java code using rxtx? Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080807/e0a0f9a1/attachment-0004.html From ajmas at sympatico.ca Thu Aug 7 18:26:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 7 Aug 2008 20:26:41 -0400 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: <4BF42297-81E2-4BB8-A89F-1D43588379AE@sympatico.ca> On 6-Aug-08, at 19:40 , Bruce Boyes wrote: >> Unless I have missed the documentation for RXTX? I javadocced the >> RXTX >> source but information (to me) is minimal. >> Somewhere I got the impression that the Sun Comm API docs is, or was, >> compatible with RXTX, what is the best docs to use in conjuntion >> with RXTX >> and where may the be available? > > Yeah, this is one of my concerns/beefs. There is little documentation > for RXTX and it isn't just the same as javaxcomm. > > I would be willing to help out writing docs for RXTX! Yes really... > esp if we can fix the Bluetooth issues. If you want to contribute documentation then the best place to do that is the wiki. If there is anything missing or that could be improved on then please do so. If there are any points that you would like to see improved, for which you don't have the knowledge then ask on the mailing list for a volunteer. Andre From florianmanschwetus at gmx.de Fri Aug 8 03:04:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Fri, 08 Aug 2008 11:04:14 +0200 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Message-ID: <489C0C0E.2020401@gmx.de> Agustin Mu?oz schrieb: > Hi, I'm still learning about serial communication and I have some > doubts. I've got this question about how to do the following thing in rxtx. > I have this hardware that connect to a PC using a serial port. These > hardware receives data from a telephone line, proccess it, and then send > it forward to the serial port. I've used a program named wincomm that > shows what information is send it through the serial port and I have the > nex behaviour: > > The hardware has a buffer where all data is stored, that cannot be sent > it through the seria port. > The program reads the first data send it by the hardware, and keep > reading the same data always. > There is a button in the application that says enable Ack, and when I > click, then the hardware start to send all the stored information, and > all the information is shown. > > I write a class, using rxtx that reads the serial port, and the same > thing happens, it remains reading the same (first) data all the time. > And I thing something like the enable Ack I'm missing. > How can I do this enable Ack from my java code using rxtx? Afaik, a look at man ascii reveals: Okt Dez Hex Char 006 6 06 ACK So, i hope this will do the job: send(6); florian > > Thanks in advance > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/5b4965f8/attachment-0004.bin From agusmunioz at gmail.com Fri Aug 8 16:31:00 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 19:31:00 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <489C0C0E.2020401@gmx.de> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> Message-ID: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Hi Florian, thanks for the answer. By send(6) you mean to get the port OutputStream and write a 6? I try that but it didn't work. Any suggestion? Thanks On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < florianmanschwetus at gmx.de> wrote: > Agustin Mu?oz schrieb: > > Hi, I'm still learning about serial communication and I have some doubts. >> I've got this question about how to do the following thing in rxtx. >> I have this hardware that connect to a PC using a serial port. These >> hardware receives data from a telephone line, proccess it, and then send it >> forward to the serial port. I've used a program named wincomm that shows >> what information is send it through the serial port and I have the nex >> behaviour: >> >> The hardware has a buffer where all data is stored, that cannot be sent >> it through the seria port. >> The program reads the first data send it by the hardware, and keep reading >> the same data always. >> There is a button in the application that says enable Ack, and when I >> click, then the hardware start to send all the stored information, and all >> the information is shown. >> >> I write a class, using rxtx that reads the serial port, and the same thing >> happens, it remains reading the same (first) data all the time. And I thing >> something like the enable Ack I'm missing. >> How can I do this enable Ack from my java code using rxtx? >> > Afaik, a look at man ascii reveals: > Okt Dez Hex Char > 006 6 06 ACK > So, i hope this will do the job: > send(6); > > florian > >> >> Thanks in advance >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/7f3fba42/attachment-0003.html From agusmunioz at gmail.com Fri Aug 8 18:39:27 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 21:39:27 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Message-ID: <988288430808081739x7f9e7889id82591d5a9e2b4f6@mail.gmail.com> Ok, Florian, it works!! my problem was that I've been sending, through the OutputStream, the bytes of 6 as a string: out.write("6".getBytes()); but then I realized that you can write an int on an OuptuStream, so I tried that and It works: out.write(6); Thank you for the guidance!! On Fri, Aug 8, 2008 at 7:31 PM, Agustin Mu?oz wrote: > Hi Florian, thanks for the answer. By send(6) you mean to get the port > OutputStream and write a 6? > > I try that but it didn't work. > > Any suggestion? > > Thanks > > > On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < > florianmanschwetus at gmx.de> wrote: > >> Agustin Mu?oz schrieb: >> >> Hi, I'm still learning about serial communication and I have some doubts. >>> I've got this question about how to do the following thing in rxtx. >>> I have this hardware that connect to a PC using a serial port. These >>> hardware receives data from a telephone line, proccess it, and then send it >>> forward to the serial port. I've used a program named wincomm that shows >>> what information is send it through the serial port and I have the nex >>> behaviour: >>> >>> The hardware has a buffer where all data is stored, that cannot be sent >>> it through the seria port. >>> The program reads the first data send it by the hardware, and keep >>> reading the same data always. >>> There is a button in the application that says enable Ack, and when I >>> click, then the hardware start to send all the stored information, and all >>> the information is shown. >>> >>> I write a class, using rxtx that reads the serial port, and the same >>> thing happens, it remains reading the same (first) data all the time. And I >>> thing something like the enable Ack I'm missing. >>> How can I do this enable Ack from my java code using rxtx? >>> >> Afaik, a look at man ascii reveals: >> Okt Dez Hex Char >> 006 6 06 ACK >> So, i hope this will do the job: >> send(6); >> >> florian >> >>> >>> Thanks in advance >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/b918ab3d/attachment-0003.html From florianmanschwetus at gmx.de Sat Aug 9 00:45:43 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Sat, 09 Aug 2008 08:45:43 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4899667C.6010706@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> Message-ID: <489D3D17.9090209@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >> Florian Manschwetus wrote: >>> Ok, sounds fine for the receiving problem. >>> But why i have to wait after each byte when sending a command squence? >>> (the for loop in send command) >> >> Hi Florian, >> I'd imagine you probably don't! You could send all bytes in one go and >> RXTX would send them. The problem is most probably the other end: >> perhaps it has a really small buffer, some non-standard UART, or a >> crazy timing issue. If you attach a terminal to your output and send >> all the bytes of a command in one go they should appear no problem. >> >> Regards, >> Michael Erskine. >> > correct with a terminal on the other end it works, my idea was that this > basic baud has some influence. Could some one explain what it is for? > > Florian To make it more clear, my problem is that i can't use: outputStream.write(byte[]); => Beamer doesn't understand the sequence. (mostly no answer when he answers then *001) when i use this construct instead: for (int i = 0; i < command.length; i++) { this.outputStream.write(command[i]); try { Thread.sleep(25); } catch (InterruptedException e) { // TODO Auto-generated catch block e.printStackTrace(); } } it works nearly reliable. So what could it be? This Basic Baud is what exactly? Florian -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080809/692304ee/attachment-0003.bin From tjarvi at qbang.org Sat Aug 9 16:37:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Aug 2008 16:37:19 -0600 (MDT) Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489D3D17.9090209@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> <489D3D17.9090209@gmx.de> Message-ID: On Sat, 9 Aug 2008, Florian Manschwetus wrote: > Florian Manschwetus schrieb: >> Michael Erskine schrieb: >>> Florian Manschwetus wrote: >>>> Ok, sounds fine for the receiving problem. >>>> But why i have to wait after each byte when sending a command squence? >>>> (the for loop in send command) >>> >>> Hi Florian, >>> I'd imagine you probably don't! You could send all bytes in one go and >>> RXTX would send them. The problem is most probably the other end: perhaps >>> it has a really small buffer, some non-standard UART, or a crazy timing >>> issue. If you attach a terminal to your output and send all the bytes of a >>> command in one go they should appear no problem. >>> >>> Regards, >>> Michael Erskine. >>> >> correct with a terminal on the other end it works, my idea was that this >> basic baud has some influence. Could some one explain what it is for? >> >> Florian > To make it more clear, > my problem is that i can't use: > outputStream.write(byte[]); > => Beamer doesn't understand the sequence. (mostly no answer when he answers > then *001) > > when i use this construct instead: > > for (int i = 0; i < command.length; i++) { > this.outputStream.write(command[i]); > try { > Thread.sleep(25); > } catch (InterruptedException e) { > // TODO Auto-generated catch block > e.printStackTrace(); > } > } > > it works nearly reliable. > > So what could it be? This Basic Baud is what exactly? > I suspect you are using the 'moon protocol' and don't know it. RXTX enables this by default. The buffer on the other end is first in first out while reading. If the buffer is full, the bits are hand carried to the moon and burried. Then if the other side reads a couple bytes, two more bytes go into the buffer followed by more moon protocol. The resulting array of bytes the other side reads may appear to be scrambled until you go to the moon, get the bits and insert them in the right place. Flow control can prevent the default moon protocol and throttles the communiation by almost writing a byte at a time as need be. Hardware flow control is preferable but software flow control should also work. Read and write can appear to hang if the other side is not connected. This is why we don't enable them all the time. If you can't use flow control, you have to take care with the moon protocol and give the other side time to read. That is what your slower version of write is doing. -- Trent Jarvi tjarvi at qbang.org From rick_knight at rlknight.com Mon Aug 4 13:25:10 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Mon, 04 Aug 2008 12:25:10 -0700 Subject: [Rxtx] Sun's Comm API? Message-ID: <48975796.4010600@rlknight.com> I have an application that requires the javax compatible version of RXTX and Sun's comm api. I've been able to download and extract the version of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api anywhere. Can someone tell me where I can find it? Or maybe send me a copy? Also, when I try to build RXTX, configure and make complete successfully but make install failes with this error libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 I've never come accross this error before. How can I get past it? Thanks, Rick From bboyes at systronix.com Mon Aug 4 19:10:01 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:10:01 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48975796.4010600@rlknight.com> References: <48975796.4010600@rlknight.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/cb9c6167/attachment-0008.html From bboyes at systronix.com Mon Aug 4 19:12:37 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:12:37 -0600 Subject: [Rxtx] Towards an RXTX release - CSR BT/USB chipset In-Reply-To: <488FB7E7.8000802@gmail.com> References: <460801A4097E3D4CA04CC64EE648584806C56CF0@ism-mail03.corp.ad.wrs.com> <13557-75390@sneakemail.com> <20980-23424@sneakemail.com> <488FB7E7.8000802@gmail.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/52236088/attachment-0008.html From tjarvi at qbang.org Mon Aug 4 19:42:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 19:42:21 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: On Mon, 4 Aug 2008, Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: > I have an application that requires the javax compatible > version of RXTX > and Sun's comm api. I've been able to download and extract > the version > of RXTX that I need (2.0-7pre2) but I can't find Sun's camm > api > anywhere. Can someone tell me where I can find it? Or maybe > send me a > > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm port > support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have just > a ZIP with only the .class JAR file - no source or docs), has a readme > with these comments: > > This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release.? The 2.0.3 release itself is > no longer distributed.? comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project.? The RxTx project (http://www.rxtx.org ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org) was opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support.? Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins.? Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > ? > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > I hope that is helpful! > It would be nice to work with Sun to resolve those longstanding issues. But it may not be practical unless the process goes as fast and painless as the grandfathering of commapi did. Another option may be the old kaffe extensions that moved to gnu classpathx. These don't have the native libraries but should provide the 2.0 interface and the javax.comm.properties mechansim for SPI. http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Mon Aug 4 20:23:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Mon, 04 Aug 2008 20:23:57 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4897B9BD.5070809@ergotech.com> Has there been any work/would it be possible, to layer a javacomm look-alike on top of the GNU code? The goal is not to move the javax code forward, but to emulate the "legacy" javax packages for people who still need this. Jim Trent Jarvi wrote: > On Mon, 4 Aug 2008, Bruce Boyes wrote: > >> At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible >> version of RXTX >> and Sun's comm api. I've been able to download and extract >> the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm >> api >> anywhere. Can someone tell me where I can find it? Or maybe >> send me a >> >> >> javaxcomm has had a sort of on-again off-again history. The windoze >> version has been languishing for years (literally) but there are newer >> versions for other OS's. >> >> We try to keep links on one of our help pages current: >> http://www.practicalembeddedjava.com/tools/javatools_list.html >> which gets you to here: >> http://java.sun.com/products/javacomm/ >> where it says in fact they no longer even support Windows and Mac: >> "Implementations of the API are currently available for Solaris SPARC, >> Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so >> someone could support it. But I guess that's part of the reason RXTX >> exists! >> >> So one of Sun's own products, SunSPOT, has to use RXTX to get comm port >> support. >> >> The version we use is 2.0 from 11/15/1998. I have posted it on our >> website, which is within the terms of the license agreement contained >> therein (as I understand it). >> >> The last version of javaxcomm for Windows, 2.0.3, (for which I have just >> a ZIP with only the .class JAR file - no source or docs), has a readme >> with these comments: >> >> This distribution contains the comm.jar file original part >> of the COMMAPI 2.0.3 release. The 2.0.3 release itself is >> no longer distributed. comm.jar, which contains the comm >> API java class files (eg. Sun's binary implementation of the >> interface classes), is being made available, unsupported, >> with no obligation to fix bugs, at the request of the RXTX >> project. The RxTx project (http://www.rxtx.org ), uses the >> comm.jar class files, but provides their own native library >> components to provide support for other platforms. >> >> The 2.0.3 comm.jar is being provided in this way because >> as of COMMAPI 3.x, the java binary implementation forked and >> became incompatible with the RxTx project's native code. >> Due to the lack of a clear business case, and to resource >> constraints, no additional resources are being >> provided to provide an alternative engineering solution >> at the time of writing. >> >> RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: >> >> Ultimately the COMMAPI would be better served if a Java >> Community Process JSR (http://www.jcp.org) was opened and >> the COMMAPI was rearchitected to provide a more pluggable >> framework to improve cross-platform support. Such an >> architecture would embody a better defined and better >> documented SPI interface, including a way for comm. ports >> to be revealed to the client application through the API >> via platform-aware plugins. Similarly, native code used >> to access comm port in general could be handled more >> flexibly using a plugin model, whereby on any platform, >> multiple native modules could be in use simultaneously. >> >> Since there are now various ways serial ports can be implemented >> and accessed, modular comm. port JNI native libraries would be >> of benefit insofar as removing the burden of over-generalization >> from any single native component, or inversely, by relieving the >> implicit constraint that comm. drivers be accessed only via a >> monolithic mechanism, such as the UNIX vnode interface. >> >> paul.klissner at sun.com >> 6/10/06 >> >> I hope that is helpful! >> > > It would be nice to work with Sun to resolve those longstanding issues. > But it may not be practical unless the process goes as fast and painless > as the grandfathering of commapi did. > > Another option may be the old kaffe extensions that moved to gnu > classpathx. These don't have the native libraries but should provide > the 2.0 interface and the javax.comm.properties mechansim for SPI. > > http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Mon Aug 4 21:09:15 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 21:09:15 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? Message-ID: Hi Jim, I will not step into the javax.comm namespace without Sun's explicite permission. I fully understand the pain point you are trying to address. In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm Linux) - which remains an integral part of rxtx. At the time it was a win for Sun and rxtx. The Sun commapi license is/was fairly clear that rxtx should not step into that namespace. It made sense as Sun was active in that space and rxtx may go into another namespace - it was an experiment in working with Sun. This may sound silly looking at something that happened almost 10 years ago. In a community of respect which Sun helped create, there is no question about what to do. I hope eventually Sun will step up and do a right thing too. I agree that this is hurting the API more than helping it. There are also questions about how to replace the API in the long term which includes HID support which isn't going well so far. Others that can't even look at Sun's javax.comm today and can look at Kaffe's contribution to classpathx can easily work around such restrictions. On Mon, 4 Aug 2008, Jim Redman wrote: > Has there been any work/would it be possible, to layer a javacomm > look-alike on top of the GNU code? > > The goal is not to move the javax code forward, but to emulate the > "legacy" javax packages for people who still need this. > > Jim > > Trent Jarvi wrote: >> >> It would be nice to work with Sun to resolve those longstanding issues. >> But it may not be practical unless the process goes as fast and painless >> as the grandfathering of commapi did. >> >> Another option may be the old kaffe extensions that moved to gnu >> classpathx. These don't have the native libraries but should provide >> the 2.0 interface and the javax.comm.properties mechansim for SPI. >> >> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From florianmanschwetus at gmx.de Tue Aug 5 05:04:46 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 13:04:46 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: References: <48971C1F.9020806@gmx.de> Message-ID: <489833CE.1040801@gmx.de> Just look at sendCommand in this method I have to place a Thread.sleep(20) after each byte send to get working. Even the event based receive doesn't work fine but this could be may stupidness. The specifikation document (it is on the last pages of the manual) for the beamer could be found on: http://www.optoma.co.uk/support.aspx Florian Manschwetus Trent Jarvi schrieb: > > Hi Florian > > Sorry for the top post in advance. I worry you may not see my answer > under all your code :) > > I have not received this email before. This is 500k of code which I > don't have time to read. I can spend about 5 min on each hobby email > and still get to work in the morning. I have a couple suggestions for > how to get an answer. > > First, cut out your comments and extra code so you can demonstrate the > question (I might even glance and see what is wrong then). Don't go for > a working final product. Isolate the problem using a simple program and > then ask with that as an example. If I did what you just did, I'd have > to post 3/4 of a million lines of code :) > > Second, join the rxtx mail-list and ask there. This will give you 100x > more eyes. I'll also read and try to follow. > > -- > taj > > > > On Mon, 4 Aug 2008, Florian Manschwetus wrote: > >> It could be that my university account is blocked by filters so >> resending from here. >> >> >> Topic is to control Optoma HD80 beamer using rs232 serial chat. >> This code is able to detect power state and switch the beamer on / off. >> connected is the beamer using a digitus usb 2.0 serial adapter with an >> FT232 USB-Serial adapter the systems architecture is amd64. >> >> Please take a look in the sendCommand routine i have to place theire >> those Thread.sleep to get it working. >> Now the question is this correct or is there a better way to get this >> working correctly? >> >> In the javadoc coming with the install i found this: >> setBaudBase >> >> public boolean setBaudBase(int BaudBase) >> throws UnsupportedCommOperationException, >> java.io.IOException >> >> Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 >> before using. >> >> could this explain the error? >> I attached my java source and the protocol description for the beamer >> (available on vendor website). >> >> thx, >> Florian Manschwetus >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: TestRS232.java Type: text/x-java Size: 9143 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0016.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0017.bin From michael.erskine at ketech.com Tue Aug 5 05:53:49 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Tue, 5 Aug 2008 12:53:49 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489833CE.1040801@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> > Just look at sendCommand in this method I have to place a > Thread.sleep(20) after each byte send to get working. Even the event > based receive doesn't work fine but this could be may stupidness. Hi Florian, Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. Regards, Michael Erskine. From florianmanschwetus at gmx.de Tue Aug 5 07:28:15 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:28:15 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> Message-ID: <4898556F.8000208@gmx.de> Michael Erskine schrieb: >> Just look at sendCommand in this method I have to place a >> Thread.sleep(20) after each byte send to get working. Even the event >> based receive doesn't work fine but this could be may stupidness. > > Hi Florian, > > Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. > > Regards, > Michael Erskine. > Ok, sounds fine for the receiving problem. But why i have to wait after each byte when sending a command squence? (the for loop in send command) Florian > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/284f350c/attachment-0007.bin From florianmanschwetus at gmx.de Tue Aug 5 07:44:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:44:14 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <4898592E.2020908@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >>> Just look at sendCommand in this method I have to place a >>> Thread.sleep(20) after each byte send to get working. Even the event >>> based receive doesn't work fine but this could be may stupidness. >> >> Hi Florian, >> >> Yes, naturally you'll have to wait for a response from the other end. >> Why not wait for notification from the event thread perhaps using a >> BlockingDeque rather than your LinkedList. Generally I >> try to decouple all input and output streams: in your case your >> application is operating synchronously like the "expect" program >> (http://expect.nist.gov/) so waits (or timeouts) will need to be >> factored in. >> >> Regards, >> Michael Erskine. >> > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) > > Florian Furthermore there is this basic baud with this confusing javadoc entry: public boolean setBaudBase(int BaudBase) throws UnsupportedCommOperationException, java.io.IOException Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 before using. maybe this could explain something Florian >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/006c7425/attachment-0007.bin From jredman at ergotech.com Tue Aug 5 09:13:36 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 05 Aug 2008 09:13:36 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: Message-ID: <48986E20.3060104@ergotech.com> Trent, So two issues: 1) Technically I'm still not sure how easy/practical a layer would be. The problems are always classes like listeners, and wrapping returns of gnu.io classes. I really see it as a "delegate" type of concept. Any thoughts or ideas of the practicality of this approach? The idea is not to modify RXTX. 2) Javax. The javax namespace does seem to be in widespread use outside of Sun (the same is true for the java namespace). The classpath extensions, or some other location, should be interested in a JavaComm implementation even if it does have dependencies on RXTX. Would you have any philosophical objection to an approach like that? Of course, I suspect it might be better if someone with that authority at Sun would admit that the javax namespace is already in the wild and that there is no problem with it being used within RXTX. Jim Trent Jarvi wrote: > Hi Jim, > > I will not step into the javax.comm namespace without Sun's explicite > permission. I fully understand the pain point you are trying to address. > > In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm > Linux) - which remains an integral part of rxtx. At the time it was a win for > Sun and rxtx. > > The Sun commapi license is/was fairly clear that rxtx should not step into that > namespace. It made sense as Sun was active in that space and rxtx may go into > another namespace - it was an experiment in working with Sun. > > This may sound silly looking at something that happened almost 10 years ago. > In a community of respect which Sun helped create, there is no question about > what to do. I hope eventually Sun will step up and do a right thing too. > > I agree that this is hurting the API more than helping it. There are also > questions about how to replace the API in the long term which includes HID > support which isn't going well so far. > > Others that can't even look at Sun's javax.comm today and can look at Kaffe's > contribution to classpathx can easily work around such restrictions. > > On Mon, 4 Aug 2008, Jim Redman wrote: > >> Has there been any work/would it be possible, to layer a javacomm >> look-alike on top of the GNU code? >> >> The goal is not to move the javax code forward, but to emulate the >> "legacy" javax packages for people who still need this. >> >> Jim >> >> Trent Jarvi wrote: >>> It would be nice to work with Sun to resolve those longstanding issues. >>> But it may not be practical unless the process goes as fast and painless >>> as the grandfathering of commapi did. >>> >>> Another option may be the old kaffe extensions that moved to gnu >>> classpathx. These don't have the native libraries but should provide >>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>> >>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From sandeep at genevasoftech.com Tue Aug 5 11:18:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Tue, 05 Aug 2008 22:48:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <48988B6C.5080409@genevasoftech.com> Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. *-- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/ad20f1cb/attachment-0007.html From Martin.Oberhuber at windriver.com Tue Aug 5 13:30:17 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Tue, 5 Aug 2008 21:30:17 +0200 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Sandeep, shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on Sol7 but I've successfully run it on Sol9 and Sol10. Or is your request really about a native 64bit variant? I'm afraid that then you're out of luck since I think that quite a bit of RXTX is not yet ready for 64 bit. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Sandeep Kumar K Sent: Tuesday, August 05, 2008 7:19 PM To: rxtx at qbang.org Subject: [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so for Solaris 9 Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. -- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/81b7f988/attachment-0007.html From tjarvi at qbang.org Tue Aug 5 22:38:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 22:38:34 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 5 Aug 2008, Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built > on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid that > then > you're out of luck since I think that quite a bit of RXTX is not yet > ready > for 64 bit. > While rxtx-2.1-7 probably has problems, The CVS code should be OK for 64 bit Solaris. If it isn't, let me know and I'll find which patch is missing. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Aug 5 23:13:00 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 23:13:00 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48986E20.3060104@ergotech.com> References: <48986E20.3060104@ergotech.com> Message-ID: On Tue, 5 Aug 2008, Jim Redman wrote: > Trent, > > So two issues: > > 1) Technically I'm still not sure how easy/practical a layer would be. The > problems are always classes like listeners, and wrapping returns of gnu.io > classes. I really see it as a "delegate" type of concept. Any thoughts or > ideas of the practicality of this approach? The idea is not to modify RXTX. I have not put too much thought into this. I assume you want what rxtx 2.0 provided to tie into javax.comm implementations. More classes could be added to rxtx 2.1-7 for SPI support. Maintaining rxtx-2.0 could also be handed to someone if they like. > > 2) Javax. The javax namespace does seem to be in widespread use outside of > Sun (the same is true for the java namespace). The classpath extensions, or > some other location, should be interested in a JavaComm implementation even > if it does have dependencies on RXTX. Would you have any philosophical > objection to an approach like that? > No problems. Classpathx would be a possible place to do it. I'd suggest thinking twice about what this involves in practical terms. You would be wanting to revive the 2.0 API while Sun is at 3.0 and grandfathering the JSR. This undermines the main reason (established api) for using the javax.comm namespace and does not leave such a project in a good position. The only win I see here is maintaining support for applications that can't migrate namespaces. Not that that isn't important. At some point it is going to be less work to just edit the bytecode :) Such a javax.comm effort would also be signing up new projects that decided to use the work up for concerns they probably will not understand or expect. That probably isn't a good path to facilitate for new projects at this time. We will put a good faith effort to work well with others but keep in mind the project has limited bandwidth for such efforts. > Of course, I suspect it might be better if someone with that authority at Sun > would admit that the javax namespace is already in the wild and that there is > no problem with it being used within RXTX. > > Jim > > Trent Jarvi wrote: >> Hi Jim, >> >> I will not step into the javax.comm namespace without Sun's explicite >> permission. I fully understand the pain point you are trying to address. >> >> In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java >> Comm Linux) - which remains an integral part of rxtx. At the time it was a >> win for Sun and rxtx. >> >> The Sun commapi license is/was fairly clear that rxtx should not step into >> that namespace. It made sense as Sun was active in that space and rxtx may >> go into another namespace - it was an experiment in working with Sun. >> >> This may sound silly looking at something that happened almost 10 years >> ago. In a community of respect which Sun helped create, there is no >> question about what to do. I hope eventually Sun will step up and do a >> right thing too. >> >> I agree that this is hurting the API more than helping it. There are also >> questions about how to replace the API in the long term which includes HID >> support which isn't going well so far. >> >> Others that can't even look at Sun's javax.comm today and can look at >> Kaffe's contribution to classpathx can easily work around such >> restrictions. >> >> On Mon, 4 Aug 2008, Jim Redman wrote: >> >>> Has there been any work/would it be possible, to layer a javacomm >>> look-alike on top of the GNU code? >>> >>> The goal is not to move the javax code forward, but to emulate the >>> "legacy" javax packages for people who still need this. >>> >>> Jim >>> >>> Trent Jarvi wrote: >>>> It would be nice to work with Sun to resolve those longstanding issues. >>>> But it may not be practical unless the process goes as fast and painless >>>> as the grandfathering of commapi did. >>>> >>>> Another option may be the old kaffe extensions that moved to gnu >>>> classpathx. These don't have the native libraries but should provide >>>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>>> >>>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From sandeep at genevasoftech.com Wed Aug 6 00:03:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Wed, 06 Aug 2008 11:33:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: <48993EB8.30107@genevasoftech.com> Thank you Mr. Martin for your suggestion. The native file which is given in rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am getting the following error . Any suggestions to solve this issue. I am using Solaris SPARC 64 bit machine. ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) thrown while loading gnu.io.RXTXCommDriver Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(Unknown Source) at java.lang.ClassLoader.loadLibrary(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) at com.ReadFromModem.main(ReadFromModem.java:84) * * *Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid > that then > you're out of luck since I think that quite a bit of RXTX is not yet ready > for 64 bit. > > Cheers, > -- > *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > ------------------------------------------------------------------------ > *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On > Behalf Of *Sandeep Kumar K > *Sent:* Tuesday, August 05, 2008 7:19 PM > *To:* rxtx at qbang.org > *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so > for Solaris 9 > > Hi, > > Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 > bit machine. The librxtxSerial.so given in website is for Solaris 8. > > *-- > > Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/1e920343/attachment-0007.html From tjarvi at qbang.org Wed Aug 6 00:21:42 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 00:21:42 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <48993EB8.30107@genevasoftech.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> <48993EB8.30107@genevasoftech.com> Message-ID: Hi Sandeep You may be out of luck unless you can compile the 2.1 src in CVS (requires gnu make and gcc). But you could try the ToyBox(R)(TM) which is a collection of WiLdLy untested cross compiled 2.1-7 binaries covering everything from the ibm z series to embeded arm/ppc. To give an idea how poorly these are tested, I don't even know if z series machines have a serial port. ftp://www.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Solaris They should at least match the binary types. Actually, I think if you use the rxtx jar from CVS with that file, it should 'work' as the fix for 64 bits was in java not the native code. You could just cd rxtx*/src; javac *.java then jar -cf RXTXcomm.jar `find -name \*.class` to create the hybrid which will complain about version information a bit. On Wed, 6 Aug 2008, Sandeep Kumar K wrote: > Thank you Mr. Martin for your suggestion. The native file which is given in > rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am > getting the following error . > Any suggestions to solve this issue. > I am using Solaris SPARC 64 bit machine. > > ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar > java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 > (Possible cause: architecture word > width mismatch) thrown while loading gnu.io.RXTXCommDriver > Exception in thread "main" java.lang.UnsatisfiedLinkError: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF > class: ELFCLASS64 (Possible cause: > architecture word width mismatch) > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(Unknown Source) > at java.lang.ClassLoader.loadLibrary(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > at com.ReadFromModem.main(ReadFromModem.java:84) > > * > * > > *Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > > > Oberhuber, Martin wrote: >> Sandeep, >> shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse >> variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on >> Sol7 but I've successfully run it on Sol9 and Sol10. >> Or is your request really about a native 64bit variant? I'm afraid that >> then >> you're out of luck since I think that quite a bit of RXTX is not yet ready >> for 64 bit. >> Cheers, >> -- >> *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> ------------------------------------------------------------------------ >> *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On >> Behalf Of *Sandeep Kumar K >> *Sent:* Tuesday, August 05, 2008 7:19 PM >> *To:* rxtx at qbang.org >> *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so >> for Solaris 9 >> >> Hi, >> >> Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 >> bit machine. The librxtxSerial.so given in website is for Solaris 8. >> >> *-- >> Thanks & Regards >> >> Sandeep Kumar K >> Sr. Software Engineer >> Geneva Software Technologies >> Whitefield, Bangalore >> Mob : 9880193454* >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> From michael.erskine at ketech.com Wed Aug 6 01:39:28 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 6 Aug 2008 08:39:28 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Florian Manschwetus wrote: > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) Hi Florian, I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. Regards, Michael Erskine. From florianmanschwetus at gmx.de Wed Aug 6 02:53:16 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 06 Aug 2008 10:53:16 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Message-ID: <4899667C.6010706@gmx.de> Michael Erskine schrieb: > Florian Manschwetus wrote: >> Ok, sounds fine for the receiving problem. >> But why i have to wait after each byte when sending a command squence? >> (the for loop in send command) > > Hi Florian, > I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. > > Regards, > Michael Erskine. > correct with a terminal on the other end it works, my idea was that this basic baud has some influence. Could some one explain what it is for? Florian > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/c2b4fa84/attachment-0007.bin From rick_knight at rlknight.com Wed Aug 6 13:01:07 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:01:07 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F4F3.3020707@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > I have an application (Readerware) that uses RXTX with Javax to access the serial port. This used to work fine under previous Linux' and Java, but something has changed, I assume with Java itself , that is causing the application to fail with a link error. The application is not able to find librxtxSerialParallel.so. RXTX supplies librxtxSerial.so and librxtxParallel.so, but not librxtxSerialParallel.so. Where can I get librxtxSerialParallel.so, or do I need it? Is something else causing the lib to not be found? Thanks, Rick Knight From rick_knight at rlknight.com Wed Aug 6 13:17:55 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:17:55 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F8E3.5060400@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Thanks for the reply. The developer of the app I'm trying to use (Readerware) has sent me a copy of the comm.api and I've copied the library (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar into the proper places. When I try to run the application, I get this error... Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: /usr/lib/libSolarisSerialParallel.so: /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not little-endian (Possible cause: endianness mismatch) Caught java.lang.UnsatisfiedLinkError: com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I while loading driver com.sun.comm.SolarisDriver Is there a way around this error? Thanks again, Rick Knight From jlar310 at gmail.com Wed Aug 6 13:37:42 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 14:37:42 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899F8E3.5060400@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > The developer of the app I'm trying to use (Readerware) has sent me a > copy of the comm.api and I've copied the library > (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar > into the proper places. When I try to run the application, I get this > error... > > Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: > /usr/lib/libSolarisSerialParallel.so: > /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not > little-endian (Possible cause: endianness mismatch) > Caught java.lang.UnsatisfiedLinkError: > com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I > > while loading driver com.sun.comm.SolarisDriver > > Is there a way around this error? What host OS are you running? From your original post it looks like 32 bit Linux. The libSolarisSerialParallel.so file is for Sun Solaris and will vary depending on the underlying hardware architecture as well. Sorry for the double post Rick, but I failed to send this to the list the first time... -- Jeff From rick_knight at rlknight.com Wed Aug 6 13:44:29 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:44:29 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: <4899FF1D.9030504@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > > >> The developer of the app I'm trying to use (Readerware) has sent me a >> copy of the comm.api and I've copied the library >> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >> into the proper places. When I try to run the application, I get this >> error... >> >> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >> /usr/lib/libSolarisSerialParallel.so: >> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >> little-endian (Possible cause: endianness mismatch) >> Caught java.lang.UnsatisfiedLinkError: >> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >> >> while loading driver com.sun.comm.SolarisDriver >> >> Is there a way around this error? >> > > What host OS are you running? From your original post it looks like 32 > bit Linux. > > The libSolarisSerialParallel.so file is for Sun Solaris and will vary > depending on the underlying hardware architecture as well. > > I'm running Kubuntu Linux (debian based). It's 32 bit. Rick Knight From jlar310 at gmail.com Wed Aug 6 15:33:23 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 16:33:23 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > I don't think Sun did binary libraries for Linux in the 2.0 version. Can someone with more historical experience than I confirm that? I recently tried to port a Comm API application from Solaris sparc to Linux x86 and likewise could not get my hands on the binary libraries. I eventually just re-wrote the code to use the gnu namespace packages and rxtx 2.1. What I don't understand is why your application vendor does not provide everything you need to run their software. FYI: I have librxtxParallel.so and librxtxSerial.so installed at JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is /usr/java/default which is actually a softlink to /usr/java/jre1.6.0_05. -- Jeff From defiantlew at yahoo.com.au Wed Aug 6 16:29:33 2008 From: defiantlew at yahoo.com.au (Lew L) Date: Thu, 7 Aug 2008 08:29:33 +1000 Subject: [Rxtx] Sun's Comm API Documentation References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> Message-ID: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> As a matter of interest is the Sun Comm API documentation available somewhere? I have tried the Sun site but it seems to have been removed. Unless I have missed the documentation for RXTX? I javadocced the RXTX source but information (to me) is minimal. Somewhere I got the impression that the Sun Comm API docs is, or was, compatible with RXTX, what is the best docs to use in conjuntion with RXTX and where may the be available? Cheers Lew From rick_knight at rlknight.com Wed Aug 6 17:18:33 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:18:33 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A3149.4050306@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff I'm not sure if I posted this here or not, but when I try to build RXTX from source I get this install error... make all-am make[1]: Entering directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' make[1]: Nothing to be done for `all-am'. make[1]: Leaving directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 Can you tell me how to get past this error and get RXTX built and installed? Thanks, Rick From bboyes at systronix.com Wed Aug 6 17:40:12 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Wed, 06 Aug 2008 17:40:12 -0600 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: At 16:29 08/06/2008, Lew L wrote: >As a matter of interest is the Sun Comm API documentation available >somewhere? I have tried the Sun site but it seems to have been removed. It's in the file we have posted, link in prev email (sorry, in a huge hurry right now). Javadocs definitely there. >Unless I have missed the documentation for RXTX? I javadocced the RXTX >source but information (to me) is minimal. >Somewhere I got the impression that the Sun Comm API docs is, or was, >compatible with RXTX, what is the best docs to use in conjuntion with RXTX >and where may the be available? Yeah, this is one of my concerns/beefs. There is little documentation for RXTX and it isn't just the same as javaxcomm. I would be willing to help out writing docs for RXTX! Yes really... esp if we can fix the Bluetooth issues. best regards Bruce >Cheers >Lew > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx ------- WWW.SYSTRONIX.COM ---------- Real embedded Java and much more +1-801-534-1017 Salt Lake City, USA From rick_knight at rlknight.com Wed Aug 6 17:54:08 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:54:08 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A39A0.2090309@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff, I would like for my vendor to switch to rxtx 2.1. It would make things much easier for me. I'm not sure why he's still using the javax compatible code. He's a small operation. Re-writing the code to use gnu namespace sounds like a major overhaul. Was it? Thanks, Rick From tjarvi at qbang.org Wed Aug 6 21:35:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:35:12 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: >> >>> Jeff wrote: >>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>>> >>>> >>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things > much easier for me. I'm not sure why he's still using the javax > compatible code. He's a small operation. Re-writing the code to use gnu > namespace sounds like a major overhaul. Was it? > Hi Jeff, The changes are fairly mechanical. Imports need to change and any explicite use of the namespace needs to change such as catching an exception. The following script was made for maintaining rxtx 2.0 but can apply to other needs. It is in the contrib dir with rxtx source. #!/bin/sh # Don't use! :) # # Sat, 03 May 2003 16:45:08 Modifications from J?rg Weule # Create a ed-cmd for the change of one pattern # case $1 in gnu) X=g/javax_comm/s+javax_comm+gnu_io+g ;; javax) X=g/gnu_io/s+gnu_io+javax_comm+g ;; *) echo;echo;echo From the top rxtx directory run;echo;echo -e \\t./ChangePackage.sh gnu;echo -e \\t\\tor;echo -e \\t./ChangePackage.sh javax;echo;echo; exit 0 ;; esac # # ed will be used to keep the owner and mode of the files unchanged. # We have run the ed-script for the characters '.' '/' as well. # "tr _ $D" do the change. # find . -type f -a -print | grep -v $0 | (while read F ; do ( echo $X; echo $X| tr _ /; echo $X| tr _ .; echo w; echo q ) | ed $F 2>&1 >/dev/null done ) # # Now we do little changes at the Makefiles. Hope that all we need. # find . -name Makefile\* -a -print | (while read F ; do cat < References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: On Thu, 7 Aug 2008, Lew L wrote: > As a matter of interest is the Sun Comm API documentation available > somewhere? I have tried the Sun site but it seems to have been removed. > > Unless I have missed the documentation for RXTX? I javadocced the RXTX > source but information (to me) is minimal. > Somewhere I got the impression that the Sun Comm API docs is, or was, > compatible with RXTX, what is the best docs to use in conjuntion with RXTX > and where may the be available? > Hi Lew, The documentation on Sun's website is accurate. The changes that are problematic in 3.0 are on the backside which rxtx used to plug into. http://java.sun.com/products/javacomm/reference/api/index.html CommPortIdentifier may have some minor differences (judging by the authors notes). -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Aug 6 21:46:08 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:46:08 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > If javax.comm.properties is properly installed and you are using a 2.0 version of Sun's commapi with rxtx 2.0, you should not see the library attempt to load libSolarisSerialParallel.so. Sun CommAPI 3.0 will not work with any version of rxtx as it is hard coded to use the shared library. See the INSTALL file with rxtx-2.0 source for more help with the properties file. -- Trent Jarvi tjarvi at qbang.org From jlar310 at gmail.com Thu Aug 7 06:32:06 2008 From: jlar310 at gmail.com (Jeff) Date: Thu, 7 Aug 2008 07:32:06 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > Jeff wrote: >> >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >> wrote: >> >>> >>> Jeff wrote: >>> >>>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>> wrote: >>>> >>>> >>>> >>>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things much > easier for me. I'm not sure why he's still using the javax compatible code. > He's a small operation. Re-writing the code to use gnu namespace sounds like > a major overhaul. Was it? I found it quite easy. In fact, in order to accommodate the transition, I actually separated all of the code that deals directly with the Comm API or RXTX into a helper class. The helper class was then coded to use reflection to determine which library was available and then instantiate the necessary objects. No direct imports of either library are used. The main application just needs to get it's hands on the IO streams and need not deal directly with the libraries. Other programs may not be so simple... But this doesn't really help you unless your vendor forks over the source code... -- Jeff From rick_knight at rlknight.com Thu Aug 7 09:47:12 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Thu, 07 Aug 2008 08:47:12 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: <489B1900.10108@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >>> wrote: >>> >>> >>>> Jeff wrote: >>>> >>>> >>>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>>> copy of the comm.api and I've copied the library >>>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>>> into the proper places. When I try to run the application, I get this >>>>>> error... >>>>>> >>>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>>> /usr/lib/libSolarisSerialParallel.so: >>>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>>> little-endian (Possible cause: endianness mismatch) >>>>>> Caught java.lang.UnsatisfiedLinkError: >>>>>> >>>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>>> >>>>>> while loading driver com.sun.comm.SolarisDriver >>>>>> >>>>>> Is there a way around this error? >>>>>> >>>>>> >>>>>> >>>>> What host OS are you running? From your original post it looks like 32 >>>>> bit Linux. >>>>> >>>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>>> depending on the underlying hardware architecture as well. >>>>> >>>>> >>>>> >>>>> >>>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>>> >>>> >>>> >>> I don't think Sun did binary libraries for Linux in the 2.0 version. >>> Can someone with more historical experience than I confirm that? >>> >>> I recently tried to port a Comm API application from Solaris sparc to >>> Linux x86 and likewise could not get my hands on the binary libraries. >>> I eventually just re-wrote the code to use the gnu namespace packages >>> and rxtx 2.1. >>> >>> What I don't understand is why your application vendor does not >>> provide everything you need to run their software. >>> >>> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >>> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >>> /usr/java/default which is actually a softlink to >>> /usr/java/jre1.6.0_05. >>> >>> >>> >> Jeff, >> >> I would like for my vendor to switch to rxtx 2.1. It would make things much >> easier for me. I'm not sure why he's still using the javax compatible code. >> He's a small operation. Re-writing the code to use gnu namespace sounds like >> a major overhaul. Was it? >> > > I found it quite easy. In fact, in order to accommodate the > transition, I actually separated all of the code that deals directly > with the Comm API or RXTX into a helper class. The helper class was > then coded to use reflection to determine which library was available > and then instantiate the necessary objects. No direct imports of > either library are used. The main application just needs to get it's > hands on the IO streams and need not deal directly with the libraries. > Other programs may not be so simple... > > But this doesn't really help you unless your vendor forks over the > source code... > > Jeff, This may not help me directly, but I'm going to forward this thread to the vendor. I think he'll be open to making things work. Thanks again, Rick Knight From agusmunioz at gmail.com Thu Aug 7 16:39:51 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Thu, 7 Aug 2008 19:39:51 -0300 Subject: [Rxtx] How to send ack? Message-ID: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Hi, I'm still learning about serial communication and I have some doubts. I've got this question about how to do the following thing in rxtx. I have this hardware that connect to a PC using a serial port. These hardware receives data from a telephone line, proccess it, and then send it forward to the serial port. I've used a program named wincomm that shows what information is send it through the serial port and I have the nex behaviour: The hardware has a buffer where all data is stored, that cannot be sent it through the seria port. The program reads the first data send it by the hardware, and keep reading the same data always. There is a button in the application that says enable Ack, and when I click, then the hardware start to send all the stored information, and all the information is shown. I write a class, using rxtx that reads the serial port, and the same thing happens, it remains reading the same (first) data all the time. And I thing something like the enable Ack I'm missing. How can I do this enable Ack from my java code using rxtx? Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080807/e0a0f9a1/attachment-0005.html From ajmas at sympatico.ca Thu Aug 7 18:26:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 7 Aug 2008 20:26:41 -0400 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: <4BF42297-81E2-4BB8-A89F-1D43588379AE@sympatico.ca> On 6-Aug-08, at 19:40 , Bruce Boyes wrote: >> Unless I have missed the documentation for RXTX? I javadocced the >> RXTX >> source but information (to me) is minimal. >> Somewhere I got the impression that the Sun Comm API docs is, or was, >> compatible with RXTX, what is the best docs to use in conjuntion >> with RXTX >> and where may the be available? > > Yeah, this is one of my concerns/beefs. There is little documentation > for RXTX and it isn't just the same as javaxcomm. > > I would be willing to help out writing docs for RXTX! Yes really... > esp if we can fix the Bluetooth issues. If you want to contribute documentation then the best place to do that is the wiki. If there is anything missing or that could be improved on then please do so. If there are any points that you would like to see improved, for which you don't have the knowledge then ask on the mailing list for a volunteer. Andre From florianmanschwetus at gmx.de Fri Aug 8 03:04:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Fri, 08 Aug 2008 11:04:14 +0200 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Message-ID: <489C0C0E.2020401@gmx.de> Agustin Mu?oz schrieb: > Hi, I'm still learning about serial communication and I have some > doubts. I've got this question about how to do the following thing in rxtx. > I have this hardware that connect to a PC using a serial port. These > hardware receives data from a telephone line, proccess it, and then send > it forward to the serial port. I've used a program named wincomm that > shows what information is send it through the serial port and I have the > nex behaviour: > > The hardware has a buffer where all data is stored, that cannot be sent > it through the seria port. > The program reads the first data send it by the hardware, and keep > reading the same data always. > There is a button in the application that says enable Ack, and when I > click, then the hardware start to send all the stored information, and > all the information is shown. > > I write a class, using rxtx that reads the serial port, and the same > thing happens, it remains reading the same (first) data all the time. > And I thing something like the enable Ack I'm missing. > How can I do this enable Ack from my java code using rxtx? Afaik, a look at man ascii reveals: Okt Dez Hex Char 006 6 06 ACK So, i hope this will do the job: send(6); florian > > Thanks in advance > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/5b4965f8/attachment-0005.bin From agusmunioz at gmail.com Fri Aug 8 16:31:00 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 19:31:00 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <489C0C0E.2020401@gmx.de> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> Message-ID: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Hi Florian, thanks for the answer. By send(6) you mean to get the port OutputStream and write a 6? I try that but it didn't work. Any suggestion? Thanks On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < florianmanschwetus at gmx.de> wrote: > Agustin Mu?oz schrieb: > > Hi, I'm still learning about serial communication and I have some doubts. >> I've got this question about how to do the following thing in rxtx. >> I have this hardware that connect to a PC using a serial port. These >> hardware receives data from a telephone line, proccess it, and then send it >> forward to the serial port. I've used a program named wincomm that shows >> what information is send it through the serial port and I have the nex >> behaviour: >> >> The hardware has a buffer where all data is stored, that cannot be sent >> it through the seria port. >> The program reads the first data send it by the hardware, and keep reading >> the same data always. >> There is a button in the application that says enable Ack, and when I >> click, then the hardware start to send all the stored information, and all >> the information is shown. >> >> I write a class, using rxtx that reads the serial port, and the same thing >> happens, it remains reading the same (first) data all the time. And I thing >> something like the enable Ack I'm missing. >> How can I do this enable Ack from my java code using rxtx? >> > Afaik, a look at man ascii reveals: > Okt Dez Hex Char > 006 6 06 ACK > So, i hope this will do the job: > send(6); > > florian > >> >> Thanks in advance >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/7f3fba42/attachment-0004.html From agusmunioz at gmail.com Fri Aug 8 18:39:27 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 21:39:27 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Message-ID: <988288430808081739x7f9e7889id82591d5a9e2b4f6@mail.gmail.com> Ok, Florian, it works!! my problem was that I've been sending, through the OutputStream, the bytes of 6 as a string: out.write("6".getBytes()); but then I realized that you can write an int on an OuptuStream, so I tried that and It works: out.write(6); Thank you for the guidance!! On Fri, Aug 8, 2008 at 7:31 PM, Agustin Mu?oz wrote: > Hi Florian, thanks for the answer. By send(6) you mean to get the port > OutputStream and write a 6? > > I try that but it didn't work. > > Any suggestion? > > Thanks > > > On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < > florianmanschwetus at gmx.de> wrote: > >> Agustin Mu?oz schrieb: >> >> Hi, I'm still learning about serial communication and I have some doubts. >>> I've got this question about how to do the following thing in rxtx. >>> I have this hardware that connect to a PC using a serial port. These >>> hardware receives data from a telephone line, proccess it, and then send it >>> forward to the serial port. I've used a program named wincomm that shows >>> what information is send it through the serial port and I have the nex >>> behaviour: >>> >>> The hardware has a buffer where all data is stored, that cannot be sent >>> it through the seria port. >>> The program reads the first data send it by the hardware, and keep >>> reading the same data always. >>> There is a button in the application that says enable Ack, and when I >>> click, then the hardware start to send all the stored information, and all >>> the information is shown. >>> >>> I write a class, using rxtx that reads the serial port, and the same >>> thing happens, it remains reading the same (first) data all the time. And I >>> thing something like the enable Ack I'm missing. >>> How can I do this enable Ack from my java code using rxtx? >>> >> Afaik, a look at man ascii reveals: >> Okt Dez Hex Char >> 006 6 06 ACK >> So, i hope this will do the job: >> send(6); >> >> florian >> >>> >>> Thanks in advance >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/b918ab3d/attachment-0004.html From florianmanschwetus at gmx.de Sat Aug 9 00:45:43 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Sat, 09 Aug 2008 08:45:43 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4899667C.6010706@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> Message-ID: <489D3D17.9090209@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >> Florian Manschwetus wrote: >>> Ok, sounds fine for the receiving problem. >>> But why i have to wait after each byte when sending a command squence? >>> (the for loop in send command) >> >> Hi Florian, >> I'd imagine you probably don't! You could send all bytes in one go and >> RXTX would send them. The problem is most probably the other end: >> perhaps it has a really small buffer, some non-standard UART, or a >> crazy timing issue. If you attach a terminal to your output and send >> all the bytes of a command in one go they should appear no problem. >> >> Regards, >> Michael Erskine. >> > correct with a terminal on the other end it works, my idea was that this > basic baud has some influence. Could some one explain what it is for? > > Florian To make it more clear, my problem is that i can't use: outputStream.write(byte[]); => Beamer doesn't understand the sequence. (mostly no answer when he answers then *001) when i use this construct instead: for (int i = 0; i < command.length; i++) { this.outputStream.write(command[i]); try { Thread.sleep(25); } catch (InterruptedException e) { // TODO Auto-generated catch block e.printStackTrace(); } } it works nearly reliable. So what could it be? This Basic Baud is what exactly? Florian -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080809/692304ee/attachment-0004.bin From tjarvi at qbang.org Sat Aug 9 16:37:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Aug 2008 16:37:19 -0600 (MDT) Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489D3D17.9090209@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> <489D3D17.9090209@gmx.de> Message-ID: On Sat, 9 Aug 2008, Florian Manschwetus wrote: > Florian Manschwetus schrieb: >> Michael Erskine schrieb: >>> Florian Manschwetus wrote: >>>> Ok, sounds fine for the receiving problem. >>>> But why i have to wait after each byte when sending a command squence? >>>> (the for loop in send command) >>> >>> Hi Florian, >>> I'd imagine you probably don't! You could send all bytes in one go and >>> RXTX would send them. The problem is most probably the other end: perhaps >>> it has a really small buffer, some non-standard UART, or a crazy timing >>> issue. If you attach a terminal to your output and send all the bytes of a >>> command in one go they should appear no problem. >>> >>> Regards, >>> Michael Erskine. >>> >> correct with a terminal on the other end it works, my idea was that this >> basic baud has some influence. Could some one explain what it is for? >> >> Florian > To make it more clear, > my problem is that i can't use: > outputStream.write(byte[]); > => Beamer doesn't understand the sequence. (mostly no answer when he answers > then *001) > > when i use this construct instead: > > for (int i = 0; i < command.length; i++) { > this.outputStream.write(command[i]); > try { > Thread.sleep(25); > } catch (InterruptedException e) { > // TODO Auto-generated catch block > e.printStackTrace(); > } > } > > it works nearly reliable. > > So what could it be? This Basic Baud is what exactly? > I suspect you are using the 'moon protocol' and don't know it. RXTX enables this by default. The buffer on the other end is first in first out while reading. If the buffer is full, the bits are hand carried to the moon and burried. Then if the other side reads a couple bytes, two more bytes go into the buffer followed by more moon protocol. The resulting array of bytes the other side reads may appear to be scrambled until you go to the moon, get the bits and insert them in the right place. Flow control can prevent the default moon protocol and throttles the communiation by almost writing a byte at a time as need be. Hardware flow control is preferable but software flow control should also work. Read and write can appear to hang if the other side is not connected. This is why we don't enable them all the time. If you can't use flow control, you have to take care with the moon protocol and give the other side time to read. That is what your slower version of write is doing. -- Trent Jarvi tjarvi at qbang.org From rxtx at allenjb.me.uk Mon Aug 11 08:06:36 2008 From: rxtx at allenjb.me.uk (AllenJB) Date: Mon, 11 Aug 2008 15:06:36 +0100 Subject: [Rxtx] Disabling EV_RXFLAG Message-ID: <48A0476C.2090800@allenjb.me.uk> Hi all, I'm working with a device which does not use an EvtChar and need to disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an event mask of FD 01 00 00. The reference software I have uses FB 00 00 00. With the rxtx mask I get framing errors which I believe are caused when the EvtChar is received. Is there currently a way with rxtx (I've using rxtx from Java) to disable EV_RXFLAG? If not from Java, where would I start if I wanted to turn the EV_RXFLAG option off in the C code? I've had a grep of the rxtx source code, but I can't see where EV_RXFLAG is being set. Thanks in advance, AllenJB From tjarvi at qbang.org Mon Aug 11 14:17:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Aug 2008 14:17:27 -0600 (MDT) Subject: [Rxtx] Disabling EV_RXFLAG In-Reply-To: <48A0476C.2090800@allenjb.me.uk> References: <48A0476C.2090800@allenjb.me.uk> Message-ID: On Mon, 11 Aug 2008, AllenJB wrote: > Hi all, > > I'm working with a device which does not use an EvtChar and need to > disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an > event mask of FD 01 00 00. The reference software I have uses FB 00 00 > 00. With the rxtx mask I get framing errors which I believe are caused > when the EvtChar is received. > > Is there currently a way with rxtx (I've using rxtx from Java) to > disable EV_RXFLAG? > > If not from Java, where would I start if I wanted to turn the EV_RXFLAG > option off in the C code? I've had a grep of the rxtx source code, but I > can't see where EV_RXFLAG is being set. > > Thanks in advance, > > AllenJB Hi Allen, I'd look at termios.c::tcsetattr() and termios.c::FillDCB() -- Trent Jarvi tjarvi at qbang.org From rick_knight at rlknight.com Mon Aug 4 13:25:10 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Mon, 04 Aug 2008 12:25:10 -0700 Subject: [Rxtx] Sun's Comm API? Message-ID: <48975796.4010600@rlknight.com> I have an application that requires the javax compatible version of RXTX and Sun's comm api. I've been able to download and extract the version of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api anywhere. Can someone tell me where I can find it? Or maybe send me a copy? Also, when I try to build RXTX, configure and make complete successfully but make install failes with this error libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 I've never come accross this error before. How can I get past it? Thanks, Rick From bboyes at systronix.com Mon Aug 4 19:10:01 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:10:01 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48975796.4010600@rlknight.com> References: <48975796.4010600@rlknight.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/cb9c6167/attachment-0009.html From bboyes at systronix.com Mon Aug 4 19:12:37 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:12:37 -0600 Subject: [Rxtx] Towards an RXTX release - CSR BT/USB chipset In-Reply-To: <488FB7E7.8000802@gmail.com> References: <460801A4097E3D4CA04CC64EE648584806C56CF0@ism-mail03.corp.ad.wrs.com> <13557-75390@sneakemail.com> <20980-23424@sneakemail.com> <488FB7E7.8000802@gmail.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/52236088/attachment-0009.html From tjarvi at qbang.org Mon Aug 4 19:42:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 19:42:21 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: On Mon, 4 Aug 2008, Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: > I have an application that requires the javax compatible > version of RXTX > and Sun's comm api. I've been able to download and extract > the version > of RXTX that I need (2.0-7pre2) but I can't find Sun's camm > api > anywhere. Can someone tell me where I can find it? Or maybe > send me a > > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm port > support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have just > a ZIP with only the .class JAR file - no source or docs), has a readme > with these comments: > > This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release.? The 2.0.3 release itself is > no longer distributed.? comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project.? The RxTx project (http://www.rxtx.org ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org) was opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support.? Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins.? Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > ? > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > I hope that is helpful! > It would be nice to work with Sun to resolve those longstanding issues. But it may not be practical unless the process goes as fast and painless as the grandfathering of commapi did. Another option may be the old kaffe extensions that moved to gnu classpathx. These don't have the native libraries but should provide the 2.0 interface and the javax.comm.properties mechansim for SPI. http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Mon Aug 4 20:23:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Mon, 04 Aug 2008 20:23:57 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4897B9BD.5070809@ergotech.com> Has there been any work/would it be possible, to layer a javacomm look-alike on top of the GNU code? The goal is not to move the javax code forward, but to emulate the "legacy" javax packages for people who still need this. Jim Trent Jarvi wrote: > On Mon, 4 Aug 2008, Bruce Boyes wrote: > >> At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible >> version of RXTX >> and Sun's comm api. I've been able to download and extract >> the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm >> api >> anywhere. Can someone tell me where I can find it? Or maybe >> send me a >> >> >> javaxcomm has had a sort of on-again off-again history. The windoze >> version has been languishing for years (literally) but there are newer >> versions for other OS's. >> >> We try to keep links on one of our help pages current: >> http://www.practicalembeddedjava.com/tools/javatools_list.html >> which gets you to here: >> http://java.sun.com/products/javacomm/ >> where it says in fact they no longer even support Windows and Mac: >> "Implementations of the API are currently available for Solaris SPARC, >> Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so >> someone could support it. But I guess that's part of the reason RXTX >> exists! >> >> So one of Sun's own products, SunSPOT, has to use RXTX to get comm port >> support. >> >> The version we use is 2.0 from 11/15/1998. I have posted it on our >> website, which is within the terms of the license agreement contained >> therein (as I understand it). >> >> The last version of javaxcomm for Windows, 2.0.3, (for which I have just >> a ZIP with only the .class JAR file - no source or docs), has a readme >> with these comments: >> >> This distribution contains the comm.jar file original part >> of the COMMAPI 2.0.3 release. The 2.0.3 release itself is >> no longer distributed. comm.jar, which contains the comm >> API java class files (eg. Sun's binary implementation of the >> interface classes), is being made available, unsupported, >> with no obligation to fix bugs, at the request of the RXTX >> project. The RxTx project (http://www.rxtx.org ), uses the >> comm.jar class files, but provides their own native library >> components to provide support for other platforms. >> >> The 2.0.3 comm.jar is being provided in this way because >> as of COMMAPI 3.x, the java binary implementation forked and >> became incompatible with the RxTx project's native code. >> Due to the lack of a clear business case, and to resource >> constraints, no additional resources are being >> provided to provide an alternative engineering solution >> at the time of writing. >> >> RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: >> >> Ultimately the COMMAPI would be better served if a Java >> Community Process JSR (http://www.jcp.org) was opened and >> the COMMAPI was rearchitected to provide a more pluggable >> framework to improve cross-platform support. Such an >> architecture would embody a better defined and better >> documented SPI interface, including a way for comm. ports >> to be revealed to the client application through the API >> via platform-aware plugins. Similarly, native code used >> to access comm port in general could be handled more >> flexibly using a plugin model, whereby on any platform, >> multiple native modules could be in use simultaneously. >> >> Since there are now various ways serial ports can be implemented >> and accessed, modular comm. port JNI native libraries would be >> of benefit insofar as removing the burden of over-generalization >> from any single native component, or inversely, by relieving the >> implicit constraint that comm. drivers be accessed only via a >> monolithic mechanism, such as the UNIX vnode interface. >> >> paul.klissner at sun.com >> 6/10/06 >> >> I hope that is helpful! >> > > It would be nice to work with Sun to resolve those longstanding issues. > But it may not be practical unless the process goes as fast and painless > as the grandfathering of commapi did. > > Another option may be the old kaffe extensions that moved to gnu > classpathx. These don't have the native libraries but should provide > the 2.0 interface and the javax.comm.properties mechansim for SPI. > > http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Mon Aug 4 21:09:15 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 21:09:15 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? Message-ID: Hi Jim, I will not step into the javax.comm namespace without Sun's explicite permission. I fully understand the pain point you are trying to address. In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm Linux) - which remains an integral part of rxtx. At the time it was a win for Sun and rxtx. The Sun commapi license is/was fairly clear that rxtx should not step into that namespace. It made sense as Sun was active in that space and rxtx may go into another namespace - it was an experiment in working with Sun. This may sound silly looking at something that happened almost 10 years ago. In a community of respect which Sun helped create, there is no question about what to do. I hope eventually Sun will step up and do a right thing too. I agree that this is hurting the API more than helping it. There are also questions about how to replace the API in the long term which includes HID support which isn't going well so far. Others that can't even look at Sun's javax.comm today and can look at Kaffe's contribution to classpathx can easily work around such restrictions. On Mon, 4 Aug 2008, Jim Redman wrote: > Has there been any work/would it be possible, to layer a javacomm > look-alike on top of the GNU code? > > The goal is not to move the javax code forward, but to emulate the > "legacy" javax packages for people who still need this. > > Jim > > Trent Jarvi wrote: >> >> It would be nice to work with Sun to resolve those longstanding issues. >> But it may not be practical unless the process goes as fast and painless >> as the grandfathering of commapi did. >> >> Another option may be the old kaffe extensions that moved to gnu >> classpathx. These don't have the native libraries but should provide >> the 2.0 interface and the javax.comm.properties mechansim for SPI. >> >> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From florianmanschwetus at gmx.de Tue Aug 5 05:04:46 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 13:04:46 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: References: <48971C1F.9020806@gmx.de> Message-ID: <489833CE.1040801@gmx.de> Just look at sendCommand in this method I have to place a Thread.sleep(20) after each byte send to get working. Even the event based receive doesn't work fine but this could be may stupidness. The specifikation document (it is on the last pages of the manual) for the beamer could be found on: http://www.optoma.co.uk/support.aspx Florian Manschwetus Trent Jarvi schrieb: > > Hi Florian > > Sorry for the top post in advance. I worry you may not see my answer > under all your code :) > > I have not received this email before. This is 500k of code which I > don't have time to read. I can spend about 5 min on each hobby email > and still get to work in the morning. I have a couple suggestions for > how to get an answer. > > First, cut out your comments and extra code so you can demonstrate the > question (I might even glance and see what is wrong then). Don't go for > a working final product. Isolate the problem using a simple program and > then ask with that as an example. If I did what you just did, I'd have > to post 3/4 of a million lines of code :) > > Second, join the rxtx mail-list and ask there. This will give you 100x > more eyes. I'll also read and try to follow. > > -- > taj > > > > On Mon, 4 Aug 2008, Florian Manschwetus wrote: > >> It could be that my university account is blocked by filters so >> resending from here. >> >> >> Topic is to control Optoma HD80 beamer using rs232 serial chat. >> This code is able to detect power state and switch the beamer on / off. >> connected is the beamer using a digitus usb 2.0 serial adapter with an >> FT232 USB-Serial adapter the systems architecture is amd64. >> >> Please take a look in the sendCommand routine i have to place theire >> those Thread.sleep to get it working. >> Now the question is this correct or is there a better way to get this >> working correctly? >> >> In the javadoc coming with the install i found this: >> setBaudBase >> >> public boolean setBaudBase(int BaudBase) >> throws UnsupportedCommOperationException, >> java.io.IOException >> >> Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 >> before using. >> >> could this explain the error? >> I attached my java source and the protocol description for the beamer >> (available on vendor website). >> >> thx, >> Florian Manschwetus >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: TestRS232.java Type: text/x-java Size: 9143 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0018.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0019.bin From michael.erskine at ketech.com Tue Aug 5 05:53:49 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Tue, 5 Aug 2008 12:53:49 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489833CE.1040801@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> > Just look at sendCommand in this method I have to place a > Thread.sleep(20) after each byte send to get working. Even the event > based receive doesn't work fine but this could be may stupidness. Hi Florian, Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. Regards, Michael Erskine. From florianmanschwetus at gmx.de Tue Aug 5 07:28:15 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:28:15 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> Message-ID: <4898556F.8000208@gmx.de> Michael Erskine schrieb: >> Just look at sendCommand in this method I have to place a >> Thread.sleep(20) after each byte send to get working. Even the event >> based receive doesn't work fine but this could be may stupidness. > > Hi Florian, > > Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. > > Regards, > Michael Erskine. > Ok, sounds fine for the receiving problem. But why i have to wait after each byte when sending a command squence? (the for loop in send command) Florian > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/284f350c/attachment-0008.bin From florianmanschwetus at gmx.de Tue Aug 5 07:44:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:44:14 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <4898592E.2020908@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >>> Just look at sendCommand in this method I have to place a >>> Thread.sleep(20) after each byte send to get working. Even the event >>> based receive doesn't work fine but this could be may stupidness. >> >> Hi Florian, >> >> Yes, naturally you'll have to wait for a response from the other end. >> Why not wait for notification from the event thread perhaps using a >> BlockingDeque rather than your LinkedList. Generally I >> try to decouple all input and output streams: in your case your >> application is operating synchronously like the "expect" program >> (http://expect.nist.gov/) so waits (or timeouts) will need to be >> factored in. >> >> Regards, >> Michael Erskine. >> > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) > > Florian Furthermore there is this basic baud with this confusing javadoc entry: public boolean setBaudBase(int BaudBase) throws UnsupportedCommOperationException, java.io.IOException Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 before using. maybe this could explain something Florian >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/006c7425/attachment-0008.bin From jredman at ergotech.com Tue Aug 5 09:13:36 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 05 Aug 2008 09:13:36 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: Message-ID: <48986E20.3060104@ergotech.com> Trent, So two issues: 1) Technically I'm still not sure how easy/practical a layer would be. The problems are always classes like listeners, and wrapping returns of gnu.io classes. I really see it as a "delegate" type of concept. Any thoughts or ideas of the practicality of this approach? The idea is not to modify RXTX. 2) Javax. The javax namespace does seem to be in widespread use outside of Sun (the same is true for the java namespace). The classpath extensions, or some other location, should be interested in a JavaComm implementation even if it does have dependencies on RXTX. Would you have any philosophical objection to an approach like that? Of course, I suspect it might be better if someone with that authority at Sun would admit that the javax namespace is already in the wild and that there is no problem with it being used within RXTX. Jim Trent Jarvi wrote: > Hi Jim, > > I will not step into the javax.comm namespace without Sun's explicite > permission. I fully understand the pain point you are trying to address. > > In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm > Linux) - which remains an integral part of rxtx. At the time it was a win for > Sun and rxtx. > > The Sun commapi license is/was fairly clear that rxtx should not step into that > namespace. It made sense as Sun was active in that space and rxtx may go into > another namespace - it was an experiment in working with Sun. > > This may sound silly looking at something that happened almost 10 years ago. > In a community of respect which Sun helped create, there is no question about > what to do. I hope eventually Sun will step up and do a right thing too. > > I agree that this is hurting the API more than helping it. There are also > questions about how to replace the API in the long term which includes HID > support which isn't going well so far. > > Others that can't even look at Sun's javax.comm today and can look at Kaffe's > contribution to classpathx can easily work around such restrictions. > > On Mon, 4 Aug 2008, Jim Redman wrote: > >> Has there been any work/would it be possible, to layer a javacomm >> look-alike on top of the GNU code? >> >> The goal is not to move the javax code forward, but to emulate the >> "legacy" javax packages for people who still need this. >> >> Jim >> >> Trent Jarvi wrote: >>> It would be nice to work with Sun to resolve those longstanding issues. >>> But it may not be practical unless the process goes as fast and painless >>> as the grandfathering of commapi did. >>> >>> Another option may be the old kaffe extensions that moved to gnu >>> classpathx. These don't have the native libraries but should provide >>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>> >>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From sandeep at genevasoftech.com Tue Aug 5 11:18:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Tue, 05 Aug 2008 22:48:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <48988B6C.5080409@genevasoftech.com> Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. *-- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/ad20f1cb/attachment-0008.html From Martin.Oberhuber at windriver.com Tue Aug 5 13:30:17 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Tue, 5 Aug 2008 21:30:17 +0200 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Sandeep, shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on Sol7 but I've successfully run it on Sol9 and Sol10. Or is your request really about a native 64bit variant? I'm afraid that then you're out of luck since I think that quite a bit of RXTX is not yet ready for 64 bit. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Sandeep Kumar K Sent: Tuesday, August 05, 2008 7:19 PM To: rxtx at qbang.org Subject: [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so for Solaris 9 Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. -- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/81b7f988/attachment-0008.html From tjarvi at qbang.org Tue Aug 5 22:38:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 22:38:34 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 5 Aug 2008, Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built > on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid that > then > you're out of luck since I think that quite a bit of RXTX is not yet > ready > for 64 bit. > While rxtx-2.1-7 probably has problems, The CVS code should be OK for 64 bit Solaris. If it isn't, let me know and I'll find which patch is missing. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Aug 5 23:13:00 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 23:13:00 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48986E20.3060104@ergotech.com> References: <48986E20.3060104@ergotech.com> Message-ID: On Tue, 5 Aug 2008, Jim Redman wrote: > Trent, > > So two issues: > > 1) Technically I'm still not sure how easy/practical a layer would be. The > problems are always classes like listeners, and wrapping returns of gnu.io > classes. I really see it as a "delegate" type of concept. Any thoughts or > ideas of the practicality of this approach? The idea is not to modify RXTX. I have not put too much thought into this. I assume you want what rxtx 2.0 provided to tie into javax.comm implementations. More classes could be added to rxtx 2.1-7 for SPI support. Maintaining rxtx-2.0 could also be handed to someone if they like. > > 2) Javax. The javax namespace does seem to be in widespread use outside of > Sun (the same is true for the java namespace). The classpath extensions, or > some other location, should be interested in a JavaComm implementation even > if it does have dependencies on RXTX. Would you have any philosophical > objection to an approach like that? > No problems. Classpathx would be a possible place to do it. I'd suggest thinking twice about what this involves in practical terms. You would be wanting to revive the 2.0 API while Sun is at 3.0 and grandfathering the JSR. This undermines the main reason (established api) for using the javax.comm namespace and does not leave such a project in a good position. The only win I see here is maintaining support for applications that can't migrate namespaces. Not that that isn't important. At some point it is going to be less work to just edit the bytecode :) Such a javax.comm effort would also be signing up new projects that decided to use the work up for concerns they probably will not understand or expect. That probably isn't a good path to facilitate for new projects at this time. We will put a good faith effort to work well with others but keep in mind the project has limited bandwidth for such efforts. > Of course, I suspect it might be better if someone with that authority at Sun > would admit that the javax namespace is already in the wild and that there is > no problem with it being used within RXTX. > > Jim > > Trent Jarvi wrote: >> Hi Jim, >> >> I will not step into the javax.comm namespace without Sun's explicite >> permission. I fully understand the pain point you are trying to address. >> >> In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java >> Comm Linux) - which remains an integral part of rxtx. At the time it was a >> win for Sun and rxtx. >> >> The Sun commapi license is/was fairly clear that rxtx should not step into >> that namespace. It made sense as Sun was active in that space and rxtx may >> go into another namespace - it was an experiment in working with Sun. >> >> This may sound silly looking at something that happened almost 10 years >> ago. In a community of respect which Sun helped create, there is no >> question about what to do. I hope eventually Sun will step up and do a >> right thing too. >> >> I agree that this is hurting the API more than helping it. There are also >> questions about how to replace the API in the long term which includes HID >> support which isn't going well so far. >> >> Others that can't even look at Sun's javax.comm today and can look at >> Kaffe's contribution to classpathx can easily work around such >> restrictions. >> >> On Mon, 4 Aug 2008, Jim Redman wrote: >> >>> Has there been any work/would it be possible, to layer a javacomm >>> look-alike on top of the GNU code? >>> >>> The goal is not to move the javax code forward, but to emulate the >>> "legacy" javax packages for people who still need this. >>> >>> Jim >>> >>> Trent Jarvi wrote: >>>> It would be nice to work with Sun to resolve those longstanding issues. >>>> But it may not be practical unless the process goes as fast and painless >>>> as the grandfathering of commapi did. >>>> >>>> Another option may be the old kaffe extensions that moved to gnu >>>> classpathx. These don't have the native libraries but should provide >>>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>>> >>>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From sandeep at genevasoftech.com Wed Aug 6 00:03:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Wed, 06 Aug 2008 11:33:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: <48993EB8.30107@genevasoftech.com> Thank you Mr. Martin for your suggestion. The native file which is given in rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am getting the following error . Any suggestions to solve this issue. I am using Solaris SPARC 64 bit machine. ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) thrown while loading gnu.io.RXTXCommDriver Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(Unknown Source) at java.lang.ClassLoader.loadLibrary(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) at com.ReadFromModem.main(ReadFromModem.java:84) * * *Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid > that then > you're out of luck since I think that quite a bit of RXTX is not yet ready > for 64 bit. > > Cheers, > -- > *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > ------------------------------------------------------------------------ > *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On > Behalf Of *Sandeep Kumar K > *Sent:* Tuesday, August 05, 2008 7:19 PM > *To:* rxtx at qbang.org > *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so > for Solaris 9 > > Hi, > > Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 > bit machine. The librxtxSerial.so given in website is for Solaris 8. > > *-- > > Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/1e920343/attachment-0008.html From tjarvi at qbang.org Wed Aug 6 00:21:42 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 00:21:42 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <48993EB8.30107@genevasoftech.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> <48993EB8.30107@genevasoftech.com> Message-ID: Hi Sandeep You may be out of luck unless you can compile the 2.1 src in CVS (requires gnu make and gcc). But you could try the ToyBox(R)(TM) which is a collection of WiLdLy untested cross compiled 2.1-7 binaries covering everything from the ibm z series to embeded arm/ppc. To give an idea how poorly these are tested, I don't even know if z series machines have a serial port. ftp://www.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Solaris They should at least match the binary types. Actually, I think if you use the rxtx jar from CVS with that file, it should 'work' as the fix for 64 bits was in java not the native code. You could just cd rxtx*/src; javac *.java then jar -cf RXTXcomm.jar `find -name \*.class` to create the hybrid which will complain about version information a bit. On Wed, 6 Aug 2008, Sandeep Kumar K wrote: > Thank you Mr. Martin for your suggestion. The native file which is given in > rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am > getting the following error . > Any suggestions to solve this issue. > I am using Solaris SPARC 64 bit machine. > > ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar > java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 > (Possible cause: architecture word > width mismatch) thrown while loading gnu.io.RXTXCommDriver > Exception in thread "main" java.lang.UnsatisfiedLinkError: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF > class: ELFCLASS64 (Possible cause: > architecture word width mismatch) > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(Unknown Source) > at java.lang.ClassLoader.loadLibrary(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > at com.ReadFromModem.main(ReadFromModem.java:84) > > * > * > > *Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > > > Oberhuber, Martin wrote: >> Sandeep, >> shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse >> variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on >> Sol7 but I've successfully run it on Sol9 and Sol10. >> Or is your request really about a native 64bit variant? I'm afraid that >> then >> you're out of luck since I think that quite a bit of RXTX is not yet ready >> for 64 bit. >> Cheers, >> -- >> *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> ------------------------------------------------------------------------ >> *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On >> Behalf Of *Sandeep Kumar K >> *Sent:* Tuesday, August 05, 2008 7:19 PM >> *To:* rxtx at qbang.org >> *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so >> for Solaris 9 >> >> Hi, >> >> Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 >> bit machine. The librxtxSerial.so given in website is for Solaris 8. >> >> *-- >> Thanks & Regards >> >> Sandeep Kumar K >> Sr. Software Engineer >> Geneva Software Technologies >> Whitefield, Bangalore >> Mob : 9880193454* >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> From michael.erskine at ketech.com Wed Aug 6 01:39:28 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 6 Aug 2008 08:39:28 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Florian Manschwetus wrote: > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) Hi Florian, I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. Regards, Michael Erskine. From florianmanschwetus at gmx.de Wed Aug 6 02:53:16 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 06 Aug 2008 10:53:16 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Message-ID: <4899667C.6010706@gmx.de> Michael Erskine schrieb: > Florian Manschwetus wrote: >> Ok, sounds fine for the receiving problem. >> But why i have to wait after each byte when sending a command squence? >> (the for loop in send command) > > Hi Florian, > I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. > > Regards, > Michael Erskine. > correct with a terminal on the other end it works, my idea was that this basic baud has some influence. Could some one explain what it is for? Florian > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/c2b4fa84/attachment-0008.bin From rick_knight at rlknight.com Wed Aug 6 13:01:07 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:01:07 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F4F3.3020707@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > I have an application (Readerware) that uses RXTX with Javax to access the serial port. This used to work fine under previous Linux' and Java, but something has changed, I assume with Java itself , that is causing the application to fail with a link error. The application is not able to find librxtxSerialParallel.so. RXTX supplies librxtxSerial.so and librxtxParallel.so, but not librxtxSerialParallel.so. Where can I get librxtxSerialParallel.so, or do I need it? Is something else causing the lib to not be found? Thanks, Rick Knight From rick_knight at rlknight.com Wed Aug 6 13:17:55 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:17:55 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F8E3.5060400@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Thanks for the reply. The developer of the app I'm trying to use (Readerware) has sent me a copy of the comm.api and I've copied the library (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar into the proper places. When I try to run the application, I get this error... Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: /usr/lib/libSolarisSerialParallel.so: /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not little-endian (Possible cause: endianness mismatch) Caught java.lang.UnsatisfiedLinkError: com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I while loading driver com.sun.comm.SolarisDriver Is there a way around this error? Thanks again, Rick Knight From jlar310 at gmail.com Wed Aug 6 13:37:42 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 14:37:42 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899F8E3.5060400@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > The developer of the app I'm trying to use (Readerware) has sent me a > copy of the comm.api and I've copied the library > (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar > into the proper places. When I try to run the application, I get this > error... > > Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: > /usr/lib/libSolarisSerialParallel.so: > /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not > little-endian (Possible cause: endianness mismatch) > Caught java.lang.UnsatisfiedLinkError: > com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I > > while loading driver com.sun.comm.SolarisDriver > > Is there a way around this error? What host OS are you running? From your original post it looks like 32 bit Linux. The libSolarisSerialParallel.so file is for Sun Solaris and will vary depending on the underlying hardware architecture as well. Sorry for the double post Rick, but I failed to send this to the list the first time... -- Jeff From rick_knight at rlknight.com Wed Aug 6 13:44:29 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:44:29 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: <4899FF1D.9030504@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > > >> The developer of the app I'm trying to use (Readerware) has sent me a >> copy of the comm.api and I've copied the library >> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >> into the proper places. When I try to run the application, I get this >> error... >> >> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >> /usr/lib/libSolarisSerialParallel.so: >> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >> little-endian (Possible cause: endianness mismatch) >> Caught java.lang.UnsatisfiedLinkError: >> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >> >> while loading driver com.sun.comm.SolarisDriver >> >> Is there a way around this error? >> > > What host OS are you running? From your original post it looks like 32 > bit Linux. > > The libSolarisSerialParallel.so file is for Sun Solaris and will vary > depending on the underlying hardware architecture as well. > > I'm running Kubuntu Linux (debian based). It's 32 bit. Rick Knight From jlar310 at gmail.com Wed Aug 6 15:33:23 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 16:33:23 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > I don't think Sun did binary libraries for Linux in the 2.0 version. Can someone with more historical experience than I confirm that? I recently tried to port a Comm API application from Solaris sparc to Linux x86 and likewise could not get my hands on the binary libraries. I eventually just re-wrote the code to use the gnu namespace packages and rxtx 2.1. What I don't understand is why your application vendor does not provide everything you need to run their software. FYI: I have librxtxParallel.so and librxtxSerial.so installed at JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is /usr/java/default which is actually a softlink to /usr/java/jre1.6.0_05. -- Jeff From defiantlew at yahoo.com.au Wed Aug 6 16:29:33 2008 From: defiantlew at yahoo.com.au (Lew L) Date: Thu, 7 Aug 2008 08:29:33 +1000 Subject: [Rxtx] Sun's Comm API Documentation References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> Message-ID: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> As a matter of interest is the Sun Comm API documentation available somewhere? I have tried the Sun site but it seems to have been removed. Unless I have missed the documentation for RXTX? I javadocced the RXTX source but information (to me) is minimal. Somewhere I got the impression that the Sun Comm API docs is, or was, compatible with RXTX, what is the best docs to use in conjuntion with RXTX and where may the be available? Cheers Lew From rick_knight at rlknight.com Wed Aug 6 17:18:33 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:18:33 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A3149.4050306@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff I'm not sure if I posted this here or not, but when I try to build RXTX from source I get this install error... make all-am make[1]: Entering directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' make[1]: Nothing to be done for `all-am'. make[1]: Leaving directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 Can you tell me how to get past this error and get RXTX built and installed? Thanks, Rick From bboyes at systronix.com Wed Aug 6 17:40:12 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Wed, 06 Aug 2008 17:40:12 -0600 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: At 16:29 08/06/2008, Lew L wrote: >As a matter of interest is the Sun Comm API documentation available >somewhere? I have tried the Sun site but it seems to have been removed. It's in the file we have posted, link in prev email (sorry, in a huge hurry right now). Javadocs definitely there. >Unless I have missed the documentation for RXTX? I javadocced the RXTX >source but information (to me) is minimal. >Somewhere I got the impression that the Sun Comm API docs is, or was, >compatible with RXTX, what is the best docs to use in conjuntion with RXTX >and where may the be available? Yeah, this is one of my concerns/beefs. There is little documentation for RXTX and it isn't just the same as javaxcomm. I would be willing to help out writing docs for RXTX! Yes really... esp if we can fix the Bluetooth issues. best regards Bruce >Cheers >Lew > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx ------- WWW.SYSTRONIX.COM ---------- Real embedded Java and much more +1-801-534-1017 Salt Lake City, USA From rick_knight at rlknight.com Wed Aug 6 17:54:08 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:54:08 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A39A0.2090309@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff, I would like for my vendor to switch to rxtx 2.1. It would make things much easier for me. I'm not sure why he's still using the javax compatible code. He's a small operation. Re-writing the code to use gnu namespace sounds like a major overhaul. Was it? Thanks, Rick From tjarvi at qbang.org Wed Aug 6 21:35:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:35:12 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: >> >>> Jeff wrote: >>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>>> >>>> >>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things > much easier for me. I'm not sure why he's still using the javax > compatible code. He's a small operation. Re-writing the code to use gnu > namespace sounds like a major overhaul. Was it? > Hi Jeff, The changes are fairly mechanical. Imports need to change and any explicite use of the namespace needs to change such as catching an exception. The following script was made for maintaining rxtx 2.0 but can apply to other needs. It is in the contrib dir with rxtx source. #!/bin/sh # Don't use! :) # # Sat, 03 May 2003 16:45:08 Modifications from J?rg Weule # Create a ed-cmd for the change of one pattern # case $1 in gnu) X=g/javax_comm/s+javax_comm+gnu_io+g ;; javax) X=g/gnu_io/s+gnu_io+javax_comm+g ;; *) echo;echo;echo From the top rxtx directory run;echo;echo -e \\t./ChangePackage.sh gnu;echo -e \\t\\tor;echo -e \\t./ChangePackage.sh javax;echo;echo; exit 0 ;; esac # # ed will be used to keep the owner and mode of the files unchanged. # We have run the ed-script for the characters '.' '/' as well. # "tr _ $D" do the change. # find . -type f -a -print | grep -v $0 | (while read F ; do ( echo $X; echo $X| tr _ /; echo $X| tr _ .; echo w; echo q ) | ed $F 2>&1 >/dev/null done ) # # Now we do little changes at the Makefiles. Hope that all we need. # find . -name Makefile\* -a -print | (while read F ; do cat < References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: On Thu, 7 Aug 2008, Lew L wrote: > As a matter of interest is the Sun Comm API documentation available > somewhere? I have tried the Sun site but it seems to have been removed. > > Unless I have missed the documentation for RXTX? I javadocced the RXTX > source but information (to me) is minimal. > Somewhere I got the impression that the Sun Comm API docs is, or was, > compatible with RXTX, what is the best docs to use in conjuntion with RXTX > and where may the be available? > Hi Lew, The documentation on Sun's website is accurate. The changes that are problematic in 3.0 are on the backside which rxtx used to plug into. http://java.sun.com/products/javacomm/reference/api/index.html CommPortIdentifier may have some minor differences (judging by the authors notes). -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Aug 6 21:46:08 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:46:08 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > If javax.comm.properties is properly installed and you are using a 2.0 version of Sun's commapi with rxtx 2.0, you should not see the library attempt to load libSolarisSerialParallel.so. Sun CommAPI 3.0 will not work with any version of rxtx as it is hard coded to use the shared library. See the INSTALL file with rxtx-2.0 source for more help with the properties file. -- Trent Jarvi tjarvi at qbang.org From jlar310 at gmail.com Thu Aug 7 06:32:06 2008 From: jlar310 at gmail.com (Jeff) Date: Thu, 7 Aug 2008 07:32:06 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > Jeff wrote: >> >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >> wrote: >> >>> >>> Jeff wrote: >>> >>>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>> wrote: >>>> >>>> >>>> >>>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things much > easier for me. I'm not sure why he's still using the javax compatible code. > He's a small operation. Re-writing the code to use gnu namespace sounds like > a major overhaul. Was it? I found it quite easy. In fact, in order to accommodate the transition, I actually separated all of the code that deals directly with the Comm API or RXTX into a helper class. The helper class was then coded to use reflection to determine which library was available and then instantiate the necessary objects. No direct imports of either library are used. The main application just needs to get it's hands on the IO streams and need not deal directly with the libraries. Other programs may not be so simple... But this doesn't really help you unless your vendor forks over the source code... -- Jeff From rick_knight at rlknight.com Thu Aug 7 09:47:12 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Thu, 07 Aug 2008 08:47:12 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: <489B1900.10108@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >>> wrote: >>> >>> >>>> Jeff wrote: >>>> >>>> >>>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>>> copy of the comm.api and I've copied the library >>>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>>> into the proper places. When I try to run the application, I get this >>>>>> error... >>>>>> >>>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>>> /usr/lib/libSolarisSerialParallel.so: >>>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>>> little-endian (Possible cause: endianness mismatch) >>>>>> Caught java.lang.UnsatisfiedLinkError: >>>>>> >>>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>>> >>>>>> while loading driver com.sun.comm.SolarisDriver >>>>>> >>>>>> Is there a way around this error? >>>>>> >>>>>> >>>>>> >>>>> What host OS are you running? From your original post it looks like 32 >>>>> bit Linux. >>>>> >>>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>>> depending on the underlying hardware architecture as well. >>>>> >>>>> >>>>> >>>>> >>>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>>> >>>> >>>> >>> I don't think Sun did binary libraries for Linux in the 2.0 version. >>> Can someone with more historical experience than I confirm that? >>> >>> I recently tried to port a Comm API application from Solaris sparc to >>> Linux x86 and likewise could not get my hands on the binary libraries. >>> I eventually just re-wrote the code to use the gnu namespace packages >>> and rxtx 2.1. >>> >>> What I don't understand is why your application vendor does not >>> provide everything you need to run their software. >>> >>> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >>> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >>> /usr/java/default which is actually a softlink to >>> /usr/java/jre1.6.0_05. >>> >>> >>> >> Jeff, >> >> I would like for my vendor to switch to rxtx 2.1. It would make things much >> easier for me. I'm not sure why he's still using the javax compatible code. >> He's a small operation. Re-writing the code to use gnu namespace sounds like >> a major overhaul. Was it? >> > > I found it quite easy. In fact, in order to accommodate the > transition, I actually separated all of the code that deals directly > with the Comm API or RXTX into a helper class. The helper class was > then coded to use reflection to determine which library was available > and then instantiate the necessary objects. No direct imports of > either library are used. The main application just needs to get it's > hands on the IO streams and need not deal directly with the libraries. > Other programs may not be so simple... > > But this doesn't really help you unless your vendor forks over the > source code... > > Jeff, This may not help me directly, but I'm going to forward this thread to the vendor. I think he'll be open to making things work. Thanks again, Rick Knight From agusmunioz at gmail.com Thu Aug 7 16:39:51 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Thu, 7 Aug 2008 19:39:51 -0300 Subject: [Rxtx] How to send ack? Message-ID: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Hi, I'm still learning about serial communication and I have some doubts. I've got this question about how to do the following thing in rxtx. I have this hardware that connect to a PC using a serial port. These hardware receives data from a telephone line, proccess it, and then send it forward to the serial port. I've used a program named wincomm that shows what information is send it through the serial port and I have the nex behaviour: The hardware has a buffer where all data is stored, that cannot be sent it through the seria port. The program reads the first data send it by the hardware, and keep reading the same data always. There is a button in the application that says enable Ack, and when I click, then the hardware start to send all the stored information, and all the information is shown. I write a class, using rxtx that reads the serial port, and the same thing happens, it remains reading the same (first) data all the time. And I thing something like the enable Ack I'm missing. How can I do this enable Ack from my java code using rxtx? Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080807/e0a0f9a1/attachment-0006.html From ajmas at sympatico.ca Thu Aug 7 18:26:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 7 Aug 2008 20:26:41 -0400 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: <4BF42297-81E2-4BB8-A89F-1D43588379AE@sympatico.ca> On 6-Aug-08, at 19:40 , Bruce Boyes wrote: >> Unless I have missed the documentation for RXTX? I javadocced the >> RXTX >> source but information (to me) is minimal. >> Somewhere I got the impression that the Sun Comm API docs is, or was, >> compatible with RXTX, what is the best docs to use in conjuntion >> with RXTX >> and where may the be available? > > Yeah, this is one of my concerns/beefs. There is little documentation > for RXTX and it isn't just the same as javaxcomm. > > I would be willing to help out writing docs for RXTX! Yes really... > esp if we can fix the Bluetooth issues. If you want to contribute documentation then the best place to do that is the wiki. If there is anything missing or that could be improved on then please do so. If there are any points that you would like to see improved, for which you don't have the knowledge then ask on the mailing list for a volunteer. Andre From florianmanschwetus at gmx.de Fri Aug 8 03:04:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Fri, 08 Aug 2008 11:04:14 +0200 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Message-ID: <489C0C0E.2020401@gmx.de> Agustin Mu?oz schrieb: > Hi, I'm still learning about serial communication and I have some > doubts. I've got this question about how to do the following thing in rxtx. > I have this hardware that connect to a PC using a serial port. These > hardware receives data from a telephone line, proccess it, and then send > it forward to the serial port. I've used a program named wincomm that > shows what information is send it through the serial port and I have the > nex behaviour: > > The hardware has a buffer where all data is stored, that cannot be sent > it through the seria port. > The program reads the first data send it by the hardware, and keep > reading the same data always. > There is a button in the application that says enable Ack, and when I > click, then the hardware start to send all the stored information, and > all the information is shown. > > I write a class, using rxtx that reads the serial port, and the same > thing happens, it remains reading the same (first) data all the time. > And I thing something like the enable Ack I'm missing. > How can I do this enable Ack from my java code using rxtx? Afaik, a look at man ascii reveals: Okt Dez Hex Char 006 6 06 ACK So, i hope this will do the job: send(6); florian > > Thanks in advance > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/5b4965f8/attachment-0006.bin From agusmunioz at gmail.com Fri Aug 8 16:31:00 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 19:31:00 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <489C0C0E.2020401@gmx.de> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> Message-ID: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Hi Florian, thanks for the answer. By send(6) you mean to get the port OutputStream and write a 6? I try that but it didn't work. Any suggestion? Thanks On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < florianmanschwetus at gmx.de> wrote: > Agustin Mu?oz schrieb: > > Hi, I'm still learning about serial communication and I have some doubts. >> I've got this question about how to do the following thing in rxtx. >> I have this hardware that connect to a PC using a serial port. These >> hardware receives data from a telephone line, proccess it, and then send it >> forward to the serial port. I've used a program named wincomm that shows >> what information is send it through the serial port and I have the nex >> behaviour: >> >> The hardware has a buffer where all data is stored, that cannot be sent >> it through the seria port. >> The program reads the first data send it by the hardware, and keep reading >> the same data always. >> There is a button in the application that says enable Ack, and when I >> click, then the hardware start to send all the stored information, and all >> the information is shown. >> >> I write a class, using rxtx that reads the serial port, and the same thing >> happens, it remains reading the same (first) data all the time. And I thing >> something like the enable Ack I'm missing. >> How can I do this enable Ack from my java code using rxtx? >> > Afaik, a look at man ascii reveals: > Okt Dez Hex Char > 006 6 06 ACK > So, i hope this will do the job: > send(6); > > florian > >> >> Thanks in advance >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/7f3fba42/attachment-0005.html From agusmunioz at gmail.com Fri Aug 8 18:39:27 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 21:39:27 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Message-ID: <988288430808081739x7f9e7889id82591d5a9e2b4f6@mail.gmail.com> Ok, Florian, it works!! my problem was that I've been sending, through the OutputStream, the bytes of 6 as a string: out.write("6".getBytes()); but then I realized that you can write an int on an OuptuStream, so I tried that and It works: out.write(6); Thank you for the guidance!! On Fri, Aug 8, 2008 at 7:31 PM, Agustin Mu?oz wrote: > Hi Florian, thanks for the answer. By send(6) you mean to get the port > OutputStream and write a 6? > > I try that but it didn't work. > > Any suggestion? > > Thanks > > > On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < > florianmanschwetus at gmx.de> wrote: > >> Agustin Mu?oz schrieb: >> >> Hi, I'm still learning about serial communication and I have some doubts. >>> I've got this question about how to do the following thing in rxtx. >>> I have this hardware that connect to a PC using a serial port. These >>> hardware receives data from a telephone line, proccess it, and then send it >>> forward to the serial port. I've used a program named wincomm that shows >>> what information is send it through the serial port and I have the nex >>> behaviour: >>> >>> The hardware has a buffer where all data is stored, that cannot be sent >>> it through the seria port. >>> The program reads the first data send it by the hardware, and keep >>> reading the same data always. >>> There is a button in the application that says enable Ack, and when I >>> click, then the hardware start to send all the stored information, and all >>> the information is shown. >>> >>> I write a class, using rxtx that reads the serial port, and the same >>> thing happens, it remains reading the same (first) data all the time. And I >>> thing something like the enable Ack I'm missing. >>> How can I do this enable Ack from my java code using rxtx? >>> >> Afaik, a look at man ascii reveals: >> Okt Dez Hex Char >> 006 6 06 ACK >> So, i hope this will do the job: >> send(6); >> >> florian >> >>> >>> Thanks in advance >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/b918ab3d/attachment-0005.html From florianmanschwetus at gmx.de Sat Aug 9 00:45:43 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Sat, 09 Aug 2008 08:45:43 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4899667C.6010706@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> Message-ID: <489D3D17.9090209@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >> Florian Manschwetus wrote: >>> Ok, sounds fine for the receiving problem. >>> But why i have to wait after each byte when sending a command squence? >>> (the for loop in send command) >> >> Hi Florian, >> I'd imagine you probably don't! You could send all bytes in one go and >> RXTX would send them. The problem is most probably the other end: >> perhaps it has a really small buffer, some non-standard UART, or a >> crazy timing issue. If you attach a terminal to your output and send >> all the bytes of a command in one go they should appear no problem. >> >> Regards, >> Michael Erskine. >> > correct with a terminal on the other end it works, my idea was that this > basic baud has some influence. Could some one explain what it is for? > > Florian To make it more clear, my problem is that i can't use: outputStream.write(byte[]); => Beamer doesn't understand the sequence. (mostly no answer when he answers then *001) when i use this construct instead: for (int i = 0; i < command.length; i++) { this.outputStream.write(command[i]); try { Thread.sleep(25); } catch (InterruptedException e) { // TODO Auto-generated catch block e.printStackTrace(); } } it works nearly reliable. So what could it be? This Basic Baud is what exactly? Florian -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080809/692304ee/attachment-0005.bin From tjarvi at qbang.org Sat Aug 9 16:37:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Aug 2008 16:37:19 -0600 (MDT) Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489D3D17.9090209@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> <489D3D17.9090209@gmx.de> Message-ID: On Sat, 9 Aug 2008, Florian Manschwetus wrote: > Florian Manschwetus schrieb: >> Michael Erskine schrieb: >>> Florian Manschwetus wrote: >>>> Ok, sounds fine for the receiving problem. >>>> But why i have to wait after each byte when sending a command squence? >>>> (the for loop in send command) >>> >>> Hi Florian, >>> I'd imagine you probably don't! You could send all bytes in one go and >>> RXTX would send them. The problem is most probably the other end: perhaps >>> it has a really small buffer, some non-standard UART, or a crazy timing >>> issue. If you attach a terminal to your output and send all the bytes of a >>> command in one go they should appear no problem. >>> >>> Regards, >>> Michael Erskine. >>> >> correct with a terminal on the other end it works, my idea was that this >> basic baud has some influence. Could some one explain what it is for? >> >> Florian > To make it more clear, > my problem is that i can't use: > outputStream.write(byte[]); > => Beamer doesn't understand the sequence. (mostly no answer when he answers > then *001) > > when i use this construct instead: > > for (int i = 0; i < command.length; i++) { > this.outputStream.write(command[i]); > try { > Thread.sleep(25); > } catch (InterruptedException e) { > // TODO Auto-generated catch block > e.printStackTrace(); > } > } > > it works nearly reliable. > > So what could it be? This Basic Baud is what exactly? > I suspect you are using the 'moon protocol' and don't know it. RXTX enables this by default. The buffer on the other end is first in first out while reading. If the buffer is full, the bits are hand carried to the moon and burried. Then if the other side reads a couple bytes, two more bytes go into the buffer followed by more moon protocol. The resulting array of bytes the other side reads may appear to be scrambled until you go to the moon, get the bits and insert them in the right place. Flow control can prevent the default moon protocol and throttles the communiation by almost writing a byte at a time as need be. Hardware flow control is preferable but software flow control should also work. Read and write can appear to hang if the other side is not connected. This is why we don't enable them all the time. If you can't use flow control, you have to take care with the moon protocol and give the other side time to read. That is what your slower version of write is doing. -- Trent Jarvi tjarvi at qbang.org From rxtx at allenjb.me.uk Mon Aug 11 08:06:36 2008 From: rxtx at allenjb.me.uk (AllenJB) Date: Mon, 11 Aug 2008 15:06:36 +0100 Subject: [Rxtx] Disabling EV_RXFLAG Message-ID: <48A0476C.2090800@allenjb.me.uk> Hi all, I'm working with a device which does not use an EvtChar and need to disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an event mask of FD 01 00 00. The reference software I have uses FB 00 00 00. With the rxtx mask I get framing errors which I believe are caused when the EvtChar is received. Is there currently a way with rxtx (I've using rxtx from Java) to disable EV_RXFLAG? If not from Java, where would I start if I wanted to turn the EV_RXFLAG option off in the C code? I've had a grep of the rxtx source code, but I can't see where EV_RXFLAG is being set. Thanks in advance, AllenJB From tjarvi at qbang.org Mon Aug 11 14:17:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Aug 2008 14:17:27 -0600 (MDT) Subject: [Rxtx] Disabling EV_RXFLAG In-Reply-To: <48A0476C.2090800@allenjb.me.uk> References: <48A0476C.2090800@allenjb.me.uk> Message-ID: On Mon, 11 Aug 2008, AllenJB wrote: > Hi all, > > I'm working with a device which does not use an EvtChar and need to > disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an > event mask of FD 01 00 00. The reference software I have uses FB 00 00 > 00. With the rxtx mask I get framing errors which I believe are caused > when the EvtChar is received. > > Is there currently a way with rxtx (I've using rxtx from Java) to > disable EV_RXFLAG? > > If not from Java, where would I start if I wanted to turn the EV_RXFLAG > option off in the C code? I've had a grep of the rxtx source code, but I > can't see where EV_RXFLAG is being set. > > Thanks in advance, > > AllenJB Hi Allen, I'd look at termios.c::tcsetattr() and termios.c::FillDCB() -- Trent Jarvi tjarvi at qbang.org From superdadusa at gmail.com Tue Aug 12 13:57:32 2008 From: superdadusa at gmail.com (John Choi) Date: Tue, 12 Aug 2008 13:57:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. Message-ID: Hi all, Just let you all know I just start to learn Java. I have download the serial comm package and the source code from open source communities.. I was able to verify with the given message string via serial monitor. when the given message string sends to the serial port then the character return added to the end of string by default if I use "Hello World" however if I changed to something else other than "Hello, World" there is no character return add to the end of string. I thing the library download from rxtx.org has implemented for the special strings. I can do like "login\n" in the string message to make character return but I don't want to add this individual custom character for each command return in every static message string I send, Can any who have done this might help me? Basically, something like this,, Write and add function to the program write a command, Reads the respond from a serial device.. Function handles multiple messages, Write: "com open" Read: Welcome to my world" expected Write: "admin" Read: Password?, expected Write: "admin" Read: you are successfully login terminal, expected. And I need to add a separate function handler handles a character return add to the each command above. If anyone can help this I can do the reset? Thank you in advance, John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SerialIO.java Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment.pl From Steffen.DETTMER at ingenico.com Wed Aug 13 02:16:38 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 13 Aug 2008 10:16:38 +0200 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: References: Message-ID: <20080813081638.GA25412@elberon.bln.de.ingenico.com> * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > I can do like "login\n" in the string message to make character > return but I don't want to add this individual custom character > for each command return in every static message string I send, and why not?! > Can any who have done this might help me? what's about with writing a small wrapper function adding the carriage return? However, this would be slow, because either you call write two times (very bad) or the string needs to be copied, \n appended and written (since you are using Java Performance probably isn't so critical). Personally I would write `"login\n"' and `username + "\n"' etc., because since it is part of the command it should be part of the command definition string. > Basically, something like this,, Write and add function to the program write > a command, Reads the respond from a serial device.. correctly reading a `line' is more difficult. If you cannot make assumptions about timeouts and/or you need to have low delay, you need to read byte wise. If you need to save CPU resources you might need to add some buffering layer that you can read byte-wise but that is reading blockwise with some small timeout (lets say for serial lines something around byte transmission time times three or so). > /* > * To change this template, choose Tools | Templates > * and open the template in the editor. > */ :) > package joliba; > > /** > * > * @author root > */ :) > // derived from SUN's examples in the javax.comm package > import java.io.*; > import java.util.*; > //import javax.comm.*; // for SUN's serial/parallel port libraries > import gnu.io.*; // for rxtxSerial library > > public class SerialIO implements Runnable, SerialPortEventListener { > static CommPortIdentifier portId; > static CommPortIdentifier saveportId; > static Enumeration portList; > InputStream inputStream; > SerialPort serialPort; > Thread readThread; You need a thread for your synchronous RPC-style protocol? > static String messageString = "Hello, world!"; > static OutputStream outputStream; > static boolean outputBufferEmptyFlag = false; > > public static void main(String[] args) { > boolean portFound = false; > String defaultPort; > > // determine the name of the serial port on several operating systems > String osname = System.getProperty("os.name","").toLowerCase(); > if ( osname.startsWith("windows") ) { > // windows > defaultPort = "COM1"; > } else if (osname.startsWith("linux")) { > // linux > defaultPort = "/dev/ttyS0"; > } else if ( osname.startsWith("mac") ) { > // mac > defaultPort = "????"; > } else { > System.out.println("Sorry, your operating system is not supported"); > return; > } Is such a construction recommended? Isn't there some abstraction (like COM1 working on any platform)? [...] > try { > // activate the OUTPUT_BUFFER_EMPTY notifier > serialPort.notifyOnOutputEmpty(true); > } catch (Exception e) { > System.out.println("Error setting event notification"); > System.out.println(e.toString()); > System.exit(-1); > } I doubt that -1 is defined, probably some 127 or so would be the result, maybe better simply `throw e'? > public void writetoport() { > System.out.println("Writing \""+messageString+"\" to "+serialPort.getName()); > try { > // write string to serial port > outputStream.write(messageString.getBytes()); > } catch (IOException e) {} > } maybe something like /** * Writes the given output string and an additional carriage * return to the current outputStream. */ public void writeStringToPort( /** The output string (without CR). */ String output ) throws IOException { String outputLine = output + "\n"; outputStream.write(outputLine.getBytes()); } ? > > public SerialIO() { > // initalize serial port > try { > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > } catch (PortInUseException e) {} if the port is in use, you continue? Wonder that this works in Java, I would assume serialPort beeing uninitialized which AFAIK is an error in Java. > try { > inputStream = serialPort.getInputStream(); > } catch (IOException e) {} > > try { > serialPort.addEventListener(this); > } catch (TooManyListenersException e) {} > > // activate the DATA_AVAILABLE notifier > serialPort.notifyOnDataAvailable(true); > > try { > // set port parameters > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > } catch (UnsupportedCommOperationException e) {} > > // start the read thread > readThread = new Thread(this); > readThread.start(); > > } I think in all those exception cases you can abort, because it is unlikely that ignoring those errors allow a successful continuation, so in this case maybe it would be better to add a throw clause to the method. > public void run() { > // first thing in the thread, we initialize the write operation > initwritetoport(); > try { > while (true) { > // write string to port, the serialEvent will read it > writetoport(); > Thread.sleep(1000); > } > } catch (InterruptedException e) {} > } Does this make sense? Your `SimpleReadApp' writes one and the same string each second? > public void serialEvent(SerialPortEvent event) { > switch (event.getEventType()) { > case SerialPortEvent.BI: > case SerialPortEvent.OE: > case SerialPortEvent.FE: > case SerialPortEvent.PE: > case SerialPortEvent.CD: > case SerialPortEvent.CTS: > case SerialPortEvent.DSR: > case SerialPortEvent.RI: > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > break; > case SerialPortEvent.DATA_AVAILABLE: > // we get here if data has been received > byte[] readBuffer = new byte[20]; > try { > // read data > while (inputStream.available() > 0) { > int numBytes = inputStream.read(readBuffer); > } > // print data > String result = new String(readBuffer); > System.out.println("Read: "+result); > } catch (IOException e) {} I doubt that this is correct. I would assume you will get a 20 bytes result always, if more bytes would be available they would be printed in a second line but if less bytes are read I'd assume that the buffer/result contains zero bytes from implicite readBuffer contents initialisation (zero is no string terminator in Java AFAIK). > break; > } > } > } oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From florianmanschwetus at gmx.de Wed Aug 13 06:09:31 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 13 Aug 2008 14:09:31 +0200 Subject: [Rxtx] someone has seen such errors? Message-ID: <48A2CEFB.90007@gmx.de> I mean my communication mostly works, but it is far from perfect could this be the reason? Florian Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/949b9947/attachment.bin From rick_knight at rlknight.com Mon Aug 4 13:25:10 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Mon, 04 Aug 2008 12:25:10 -0700 Subject: [Rxtx] Sun's Comm API? Message-ID: <48975796.4010600@rlknight.com> I have an application that requires the javax compatible version of RXTX and Sun's comm api. I've been able to download and extract the version of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api anywhere. Can someone tell me where I can find it? Or maybe send me a copy? Also, when I try to build RXTX, configure and make complete successfully but make install failes with this error libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 I've never come accross this error before. How can I get past it? Thanks, Rick From bboyes at systronix.com Mon Aug 4 19:10:01 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:10:01 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48975796.4010600@rlknight.com> References: <48975796.4010600@rlknight.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/cb9c6167/attachment-0010.html From bboyes at systronix.com Mon Aug 4 19:12:37 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:12:37 -0600 Subject: [Rxtx] Towards an RXTX release - CSR BT/USB chipset In-Reply-To: <488FB7E7.8000802@gmail.com> References: <460801A4097E3D4CA04CC64EE648584806C56CF0@ism-mail03.corp.ad.wrs.com> <13557-75390@sneakemail.com> <20980-23424@sneakemail.com> <488FB7E7.8000802@gmail.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/52236088/attachment-0010.html From tjarvi at qbang.org Mon Aug 4 19:42:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 19:42:21 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: On Mon, 4 Aug 2008, Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: > I have an application that requires the javax compatible > version of RXTX > and Sun's comm api. I've been able to download and extract > the version > of RXTX that I need (2.0-7pre2) but I can't find Sun's camm > api > anywhere. Can someone tell me where I can find it? Or maybe > send me a > > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm port > support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have just > a ZIP with only the .class JAR file - no source or docs), has a readme > with these comments: > > This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release.? The 2.0.3 release itself is > no longer distributed.? comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project.? The RxTx project (http://www.rxtx.org ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org) was opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support.? Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins.? Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > ? > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > I hope that is helpful! > It would be nice to work with Sun to resolve those longstanding issues. But it may not be practical unless the process goes as fast and painless as the grandfathering of commapi did. Another option may be the old kaffe extensions that moved to gnu classpathx. These don't have the native libraries but should provide the 2.0 interface and the javax.comm.properties mechansim for SPI. http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Mon Aug 4 20:23:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Mon, 04 Aug 2008 20:23:57 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4897B9BD.5070809@ergotech.com> Has there been any work/would it be possible, to layer a javacomm look-alike on top of the GNU code? The goal is not to move the javax code forward, but to emulate the "legacy" javax packages for people who still need this. Jim Trent Jarvi wrote: > On Mon, 4 Aug 2008, Bruce Boyes wrote: > >> At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible >> version of RXTX >> and Sun's comm api. I've been able to download and extract >> the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm >> api >> anywhere. Can someone tell me where I can find it? Or maybe >> send me a >> >> >> javaxcomm has had a sort of on-again off-again history. The windoze >> version has been languishing for years (literally) but there are newer >> versions for other OS's. >> >> We try to keep links on one of our help pages current: >> http://www.practicalembeddedjava.com/tools/javatools_list.html >> which gets you to here: >> http://java.sun.com/products/javacomm/ >> where it says in fact they no longer even support Windows and Mac: >> "Implementations of the API are currently available for Solaris SPARC, >> Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so >> someone could support it. But I guess that's part of the reason RXTX >> exists! >> >> So one of Sun's own products, SunSPOT, has to use RXTX to get comm port >> support. >> >> The version we use is 2.0 from 11/15/1998. I have posted it on our >> website, which is within the terms of the license agreement contained >> therein (as I understand it). >> >> The last version of javaxcomm for Windows, 2.0.3, (for which I have just >> a ZIP with only the .class JAR file - no source or docs), has a readme >> with these comments: >> >> This distribution contains the comm.jar file original part >> of the COMMAPI 2.0.3 release. The 2.0.3 release itself is >> no longer distributed. comm.jar, which contains the comm >> API java class files (eg. Sun's binary implementation of the >> interface classes), is being made available, unsupported, >> with no obligation to fix bugs, at the request of the RXTX >> project. The RxTx project (http://www.rxtx.org ), uses the >> comm.jar class files, but provides their own native library >> components to provide support for other platforms. >> >> The 2.0.3 comm.jar is being provided in this way because >> as of COMMAPI 3.x, the java binary implementation forked and >> became incompatible with the RxTx project's native code. >> Due to the lack of a clear business case, and to resource >> constraints, no additional resources are being >> provided to provide an alternative engineering solution >> at the time of writing. >> >> RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: >> >> Ultimately the COMMAPI would be better served if a Java >> Community Process JSR (http://www.jcp.org) was opened and >> the COMMAPI was rearchitected to provide a more pluggable >> framework to improve cross-platform support. Such an >> architecture would embody a better defined and better >> documented SPI interface, including a way for comm. ports >> to be revealed to the client application through the API >> via platform-aware plugins. Similarly, native code used >> to access comm port in general could be handled more >> flexibly using a plugin model, whereby on any platform, >> multiple native modules could be in use simultaneously. >> >> Since there are now various ways serial ports can be implemented >> and accessed, modular comm. port JNI native libraries would be >> of benefit insofar as removing the burden of over-generalization >> from any single native component, or inversely, by relieving the >> implicit constraint that comm. drivers be accessed only via a >> monolithic mechanism, such as the UNIX vnode interface. >> >> paul.klissner at sun.com >> 6/10/06 >> >> I hope that is helpful! >> > > It would be nice to work with Sun to resolve those longstanding issues. > But it may not be practical unless the process goes as fast and painless > as the grandfathering of commapi did. > > Another option may be the old kaffe extensions that moved to gnu > classpathx. These don't have the native libraries but should provide > the 2.0 interface and the javax.comm.properties mechansim for SPI. > > http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Mon Aug 4 21:09:15 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 21:09:15 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? Message-ID: Hi Jim, I will not step into the javax.comm namespace without Sun's explicite permission. I fully understand the pain point you are trying to address. In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm Linux) - which remains an integral part of rxtx. At the time it was a win for Sun and rxtx. The Sun commapi license is/was fairly clear that rxtx should not step into that namespace. It made sense as Sun was active in that space and rxtx may go into another namespace - it was an experiment in working with Sun. This may sound silly looking at something that happened almost 10 years ago. In a community of respect which Sun helped create, there is no question about what to do. I hope eventually Sun will step up and do a right thing too. I agree that this is hurting the API more than helping it. There are also questions about how to replace the API in the long term which includes HID support which isn't going well so far. Others that can't even look at Sun's javax.comm today and can look at Kaffe's contribution to classpathx can easily work around such restrictions. On Mon, 4 Aug 2008, Jim Redman wrote: > Has there been any work/would it be possible, to layer a javacomm > look-alike on top of the GNU code? > > The goal is not to move the javax code forward, but to emulate the > "legacy" javax packages for people who still need this. > > Jim > > Trent Jarvi wrote: >> >> It would be nice to work with Sun to resolve those longstanding issues. >> But it may not be practical unless the process goes as fast and painless >> as the grandfathering of commapi did. >> >> Another option may be the old kaffe extensions that moved to gnu >> classpathx. These don't have the native libraries but should provide >> the 2.0 interface and the javax.comm.properties mechansim for SPI. >> >> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From florianmanschwetus at gmx.de Tue Aug 5 05:04:46 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 13:04:46 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: References: <48971C1F.9020806@gmx.de> Message-ID: <489833CE.1040801@gmx.de> Just look at sendCommand in this method I have to place a Thread.sleep(20) after each byte send to get working. Even the event based receive doesn't work fine but this could be may stupidness. The specifikation document (it is on the last pages of the manual) for the beamer could be found on: http://www.optoma.co.uk/support.aspx Florian Manschwetus Trent Jarvi schrieb: > > Hi Florian > > Sorry for the top post in advance. I worry you may not see my answer > under all your code :) > > I have not received this email before. This is 500k of code which I > don't have time to read. I can spend about 5 min on each hobby email > and still get to work in the morning. I have a couple suggestions for > how to get an answer. > > First, cut out your comments and extra code so you can demonstrate the > question (I might even glance and see what is wrong then). Don't go for > a working final product. Isolate the problem using a simple program and > then ask with that as an example. If I did what you just did, I'd have > to post 3/4 of a million lines of code :) > > Second, join the rxtx mail-list and ask there. This will give you 100x > more eyes. I'll also read and try to follow. > > -- > taj > > > > On Mon, 4 Aug 2008, Florian Manschwetus wrote: > >> It could be that my university account is blocked by filters so >> resending from here. >> >> >> Topic is to control Optoma HD80 beamer using rs232 serial chat. >> This code is able to detect power state and switch the beamer on / off. >> connected is the beamer using a digitus usb 2.0 serial adapter with an >> FT232 USB-Serial adapter the systems architecture is amd64. >> >> Please take a look in the sendCommand routine i have to place theire >> those Thread.sleep to get it working. >> Now the question is this correct or is there a better way to get this >> working correctly? >> >> In the javadoc coming with the install i found this: >> setBaudBase >> >> public boolean setBaudBase(int BaudBase) >> throws UnsupportedCommOperationException, >> java.io.IOException >> >> Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 >> before using. >> >> could this explain the error? >> I attached my java source and the protocol description for the beamer >> (available on vendor website). >> >> thx, >> Florian Manschwetus >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: TestRS232.java Type: text/x-java Size: 9143 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0020.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0021.bin From michael.erskine at ketech.com Tue Aug 5 05:53:49 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Tue, 5 Aug 2008 12:53:49 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489833CE.1040801@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> > Just look at sendCommand in this method I have to place a > Thread.sleep(20) after each byte send to get working. Even the event > based receive doesn't work fine but this could be may stupidness. Hi Florian, Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. Regards, Michael Erskine. From florianmanschwetus at gmx.de Tue Aug 5 07:28:15 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:28:15 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> Message-ID: <4898556F.8000208@gmx.de> Michael Erskine schrieb: >> Just look at sendCommand in this method I have to place a >> Thread.sleep(20) after each byte send to get working. Even the event >> based receive doesn't work fine but this could be may stupidness. > > Hi Florian, > > Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. > > Regards, > Michael Erskine. > Ok, sounds fine for the receiving problem. But why i have to wait after each byte when sending a command squence? (the for loop in send command) Florian > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/284f350c/attachment-0009.bin From florianmanschwetus at gmx.de Tue Aug 5 07:44:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:44:14 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <4898592E.2020908@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >>> Just look at sendCommand in this method I have to place a >>> Thread.sleep(20) after each byte send to get working. Even the event >>> based receive doesn't work fine but this could be may stupidness. >> >> Hi Florian, >> >> Yes, naturally you'll have to wait for a response from the other end. >> Why not wait for notification from the event thread perhaps using a >> BlockingDeque rather than your LinkedList. Generally I >> try to decouple all input and output streams: in your case your >> application is operating synchronously like the "expect" program >> (http://expect.nist.gov/) so waits (or timeouts) will need to be >> factored in. >> >> Regards, >> Michael Erskine. >> > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) > > Florian Furthermore there is this basic baud with this confusing javadoc entry: public boolean setBaudBase(int BaudBase) throws UnsupportedCommOperationException, java.io.IOException Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 before using. maybe this could explain something Florian >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/006c7425/attachment-0009.bin From jredman at ergotech.com Tue Aug 5 09:13:36 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 05 Aug 2008 09:13:36 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: Message-ID: <48986E20.3060104@ergotech.com> Trent, So two issues: 1) Technically I'm still not sure how easy/practical a layer would be. The problems are always classes like listeners, and wrapping returns of gnu.io classes. I really see it as a "delegate" type of concept. Any thoughts or ideas of the practicality of this approach? The idea is not to modify RXTX. 2) Javax. The javax namespace does seem to be in widespread use outside of Sun (the same is true for the java namespace). The classpath extensions, or some other location, should be interested in a JavaComm implementation even if it does have dependencies on RXTX. Would you have any philosophical objection to an approach like that? Of course, I suspect it might be better if someone with that authority at Sun would admit that the javax namespace is already in the wild and that there is no problem with it being used within RXTX. Jim Trent Jarvi wrote: > Hi Jim, > > I will not step into the javax.comm namespace without Sun's explicite > permission. I fully understand the pain point you are trying to address. > > In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm > Linux) - which remains an integral part of rxtx. At the time it was a win for > Sun and rxtx. > > The Sun commapi license is/was fairly clear that rxtx should not step into that > namespace. It made sense as Sun was active in that space and rxtx may go into > another namespace - it was an experiment in working with Sun. > > This may sound silly looking at something that happened almost 10 years ago. > In a community of respect which Sun helped create, there is no question about > what to do. I hope eventually Sun will step up and do a right thing too. > > I agree that this is hurting the API more than helping it. There are also > questions about how to replace the API in the long term which includes HID > support which isn't going well so far. > > Others that can't even look at Sun's javax.comm today and can look at Kaffe's > contribution to classpathx can easily work around such restrictions. > > On Mon, 4 Aug 2008, Jim Redman wrote: > >> Has there been any work/would it be possible, to layer a javacomm >> look-alike on top of the GNU code? >> >> The goal is not to move the javax code forward, but to emulate the >> "legacy" javax packages for people who still need this. >> >> Jim >> >> Trent Jarvi wrote: >>> It would be nice to work with Sun to resolve those longstanding issues. >>> But it may not be practical unless the process goes as fast and painless >>> as the grandfathering of commapi did. >>> >>> Another option may be the old kaffe extensions that moved to gnu >>> classpathx. These don't have the native libraries but should provide >>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>> >>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From sandeep at genevasoftech.com Tue Aug 5 11:18:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Tue, 05 Aug 2008 22:48:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <48988B6C.5080409@genevasoftech.com> Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. *-- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/ad20f1cb/attachment-0009.html From Martin.Oberhuber at windriver.com Tue Aug 5 13:30:17 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Tue, 5 Aug 2008 21:30:17 +0200 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Sandeep, shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on Sol7 but I've successfully run it on Sol9 and Sol10. Or is your request really about a native 64bit variant? I'm afraid that then you're out of luck since I think that quite a bit of RXTX is not yet ready for 64 bit. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Sandeep Kumar K Sent: Tuesday, August 05, 2008 7:19 PM To: rxtx at qbang.org Subject: [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so for Solaris 9 Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. -- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/81b7f988/attachment-0009.html From tjarvi at qbang.org Tue Aug 5 22:38:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 22:38:34 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 5 Aug 2008, Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built > on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid that > then > you're out of luck since I think that quite a bit of RXTX is not yet > ready > for 64 bit. > While rxtx-2.1-7 probably has problems, The CVS code should be OK for 64 bit Solaris. If it isn't, let me know and I'll find which patch is missing. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Aug 5 23:13:00 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 23:13:00 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48986E20.3060104@ergotech.com> References: <48986E20.3060104@ergotech.com> Message-ID: On Tue, 5 Aug 2008, Jim Redman wrote: > Trent, > > So two issues: > > 1) Technically I'm still not sure how easy/practical a layer would be. The > problems are always classes like listeners, and wrapping returns of gnu.io > classes. I really see it as a "delegate" type of concept. Any thoughts or > ideas of the practicality of this approach? The idea is not to modify RXTX. I have not put too much thought into this. I assume you want what rxtx 2.0 provided to tie into javax.comm implementations. More classes could be added to rxtx 2.1-7 for SPI support. Maintaining rxtx-2.0 could also be handed to someone if they like. > > 2) Javax. The javax namespace does seem to be in widespread use outside of > Sun (the same is true for the java namespace). The classpath extensions, or > some other location, should be interested in a JavaComm implementation even > if it does have dependencies on RXTX. Would you have any philosophical > objection to an approach like that? > No problems. Classpathx would be a possible place to do it. I'd suggest thinking twice about what this involves in practical terms. You would be wanting to revive the 2.0 API while Sun is at 3.0 and grandfathering the JSR. This undermines the main reason (established api) for using the javax.comm namespace and does not leave such a project in a good position. The only win I see here is maintaining support for applications that can't migrate namespaces. Not that that isn't important. At some point it is going to be less work to just edit the bytecode :) Such a javax.comm effort would also be signing up new projects that decided to use the work up for concerns they probably will not understand or expect. That probably isn't a good path to facilitate for new projects at this time. We will put a good faith effort to work well with others but keep in mind the project has limited bandwidth for such efforts. > Of course, I suspect it might be better if someone with that authority at Sun > would admit that the javax namespace is already in the wild and that there is > no problem with it being used within RXTX. > > Jim > > Trent Jarvi wrote: >> Hi Jim, >> >> I will not step into the javax.comm namespace without Sun's explicite >> permission. I fully understand the pain point you are trying to address. >> >> In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java >> Comm Linux) - which remains an integral part of rxtx. At the time it was a >> win for Sun and rxtx. >> >> The Sun commapi license is/was fairly clear that rxtx should not step into >> that namespace. It made sense as Sun was active in that space and rxtx may >> go into another namespace - it was an experiment in working with Sun. >> >> This may sound silly looking at something that happened almost 10 years >> ago. In a community of respect which Sun helped create, there is no >> question about what to do. I hope eventually Sun will step up and do a >> right thing too. >> >> I agree that this is hurting the API more than helping it. There are also >> questions about how to replace the API in the long term which includes HID >> support which isn't going well so far. >> >> Others that can't even look at Sun's javax.comm today and can look at >> Kaffe's contribution to classpathx can easily work around such >> restrictions. >> >> On Mon, 4 Aug 2008, Jim Redman wrote: >> >>> Has there been any work/would it be possible, to layer a javacomm >>> look-alike on top of the GNU code? >>> >>> The goal is not to move the javax code forward, but to emulate the >>> "legacy" javax packages for people who still need this. >>> >>> Jim >>> >>> Trent Jarvi wrote: >>>> It would be nice to work with Sun to resolve those longstanding issues. >>>> But it may not be practical unless the process goes as fast and painless >>>> as the grandfathering of commapi did. >>>> >>>> Another option may be the old kaffe extensions that moved to gnu >>>> classpathx. These don't have the native libraries but should provide >>>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>>> >>>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From sandeep at genevasoftech.com Wed Aug 6 00:03:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Wed, 06 Aug 2008 11:33:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: <48993EB8.30107@genevasoftech.com> Thank you Mr. Martin for your suggestion. The native file which is given in rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am getting the following error . Any suggestions to solve this issue. I am using Solaris SPARC 64 bit machine. ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) thrown while loading gnu.io.RXTXCommDriver Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(Unknown Source) at java.lang.ClassLoader.loadLibrary(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) at com.ReadFromModem.main(ReadFromModem.java:84) * * *Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid > that then > you're out of luck since I think that quite a bit of RXTX is not yet ready > for 64 bit. > > Cheers, > -- > *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > ------------------------------------------------------------------------ > *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On > Behalf Of *Sandeep Kumar K > *Sent:* Tuesday, August 05, 2008 7:19 PM > *To:* rxtx at qbang.org > *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so > for Solaris 9 > > Hi, > > Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 > bit machine. The librxtxSerial.so given in website is for Solaris 8. > > *-- > > Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/1e920343/attachment-0009.html From tjarvi at qbang.org Wed Aug 6 00:21:42 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 00:21:42 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <48993EB8.30107@genevasoftech.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> <48993EB8.30107@genevasoftech.com> Message-ID: Hi Sandeep You may be out of luck unless you can compile the 2.1 src in CVS (requires gnu make and gcc). But you could try the ToyBox(R)(TM) which is a collection of WiLdLy untested cross compiled 2.1-7 binaries covering everything from the ibm z series to embeded arm/ppc. To give an idea how poorly these are tested, I don't even know if z series machines have a serial port. ftp://www.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Solaris They should at least match the binary types. Actually, I think if you use the rxtx jar from CVS with that file, it should 'work' as the fix for 64 bits was in java not the native code. You could just cd rxtx*/src; javac *.java then jar -cf RXTXcomm.jar `find -name \*.class` to create the hybrid which will complain about version information a bit. On Wed, 6 Aug 2008, Sandeep Kumar K wrote: > Thank you Mr. Martin for your suggestion. The native file which is given in > rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am > getting the following error . > Any suggestions to solve this issue. > I am using Solaris SPARC 64 bit machine. > > ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar > java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 > (Possible cause: architecture word > width mismatch) thrown while loading gnu.io.RXTXCommDriver > Exception in thread "main" java.lang.UnsatisfiedLinkError: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF > class: ELFCLASS64 (Possible cause: > architecture word width mismatch) > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(Unknown Source) > at java.lang.ClassLoader.loadLibrary(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > at com.ReadFromModem.main(ReadFromModem.java:84) > > * > * > > *Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > > > Oberhuber, Martin wrote: >> Sandeep, >> shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse >> variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on >> Sol7 but I've successfully run it on Sol9 and Sol10. >> Or is your request really about a native 64bit variant? I'm afraid that >> then >> you're out of luck since I think that quite a bit of RXTX is not yet ready >> for 64 bit. >> Cheers, >> -- >> *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> ------------------------------------------------------------------------ >> *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On >> Behalf Of *Sandeep Kumar K >> *Sent:* Tuesday, August 05, 2008 7:19 PM >> *To:* rxtx at qbang.org >> *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so >> for Solaris 9 >> >> Hi, >> >> Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 >> bit machine. The librxtxSerial.so given in website is for Solaris 8. >> >> *-- >> Thanks & Regards >> >> Sandeep Kumar K >> Sr. Software Engineer >> Geneva Software Technologies >> Whitefield, Bangalore >> Mob : 9880193454* >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> From michael.erskine at ketech.com Wed Aug 6 01:39:28 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 6 Aug 2008 08:39:28 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Florian Manschwetus wrote: > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) Hi Florian, I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. Regards, Michael Erskine. From florianmanschwetus at gmx.de Wed Aug 6 02:53:16 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 06 Aug 2008 10:53:16 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Message-ID: <4899667C.6010706@gmx.de> Michael Erskine schrieb: > Florian Manschwetus wrote: >> Ok, sounds fine for the receiving problem. >> But why i have to wait after each byte when sending a command squence? >> (the for loop in send command) > > Hi Florian, > I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. > > Regards, > Michael Erskine. > correct with a terminal on the other end it works, my idea was that this basic baud has some influence. Could some one explain what it is for? Florian > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/c2b4fa84/attachment-0009.bin From rick_knight at rlknight.com Wed Aug 6 13:01:07 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:01:07 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F4F3.3020707@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > I have an application (Readerware) that uses RXTX with Javax to access the serial port. This used to work fine under previous Linux' and Java, but something has changed, I assume with Java itself , that is causing the application to fail with a link error. The application is not able to find librxtxSerialParallel.so. RXTX supplies librxtxSerial.so and librxtxParallel.so, but not librxtxSerialParallel.so. Where can I get librxtxSerialParallel.so, or do I need it? Is something else causing the lib to not be found? Thanks, Rick Knight From rick_knight at rlknight.com Wed Aug 6 13:17:55 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:17:55 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F8E3.5060400@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Thanks for the reply. The developer of the app I'm trying to use (Readerware) has sent me a copy of the comm.api and I've copied the library (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar into the proper places. When I try to run the application, I get this error... Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: /usr/lib/libSolarisSerialParallel.so: /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not little-endian (Possible cause: endianness mismatch) Caught java.lang.UnsatisfiedLinkError: com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I while loading driver com.sun.comm.SolarisDriver Is there a way around this error? Thanks again, Rick Knight From jlar310 at gmail.com Wed Aug 6 13:37:42 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 14:37:42 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899F8E3.5060400@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > The developer of the app I'm trying to use (Readerware) has sent me a > copy of the comm.api and I've copied the library > (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar > into the proper places. When I try to run the application, I get this > error... > > Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: > /usr/lib/libSolarisSerialParallel.so: > /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not > little-endian (Possible cause: endianness mismatch) > Caught java.lang.UnsatisfiedLinkError: > com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I > > while loading driver com.sun.comm.SolarisDriver > > Is there a way around this error? What host OS are you running? From your original post it looks like 32 bit Linux. The libSolarisSerialParallel.so file is for Sun Solaris and will vary depending on the underlying hardware architecture as well. Sorry for the double post Rick, but I failed to send this to the list the first time... -- Jeff From rick_knight at rlknight.com Wed Aug 6 13:44:29 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:44:29 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: <4899FF1D.9030504@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > > >> The developer of the app I'm trying to use (Readerware) has sent me a >> copy of the comm.api and I've copied the library >> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >> into the proper places. When I try to run the application, I get this >> error... >> >> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >> /usr/lib/libSolarisSerialParallel.so: >> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >> little-endian (Possible cause: endianness mismatch) >> Caught java.lang.UnsatisfiedLinkError: >> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >> >> while loading driver com.sun.comm.SolarisDriver >> >> Is there a way around this error? >> > > What host OS are you running? From your original post it looks like 32 > bit Linux. > > The libSolarisSerialParallel.so file is for Sun Solaris and will vary > depending on the underlying hardware architecture as well. > > I'm running Kubuntu Linux (debian based). It's 32 bit. Rick Knight From jlar310 at gmail.com Wed Aug 6 15:33:23 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 16:33:23 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > I don't think Sun did binary libraries for Linux in the 2.0 version. Can someone with more historical experience than I confirm that? I recently tried to port a Comm API application from Solaris sparc to Linux x86 and likewise could not get my hands on the binary libraries. I eventually just re-wrote the code to use the gnu namespace packages and rxtx 2.1. What I don't understand is why your application vendor does not provide everything you need to run their software. FYI: I have librxtxParallel.so and librxtxSerial.so installed at JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is /usr/java/default which is actually a softlink to /usr/java/jre1.6.0_05. -- Jeff From defiantlew at yahoo.com.au Wed Aug 6 16:29:33 2008 From: defiantlew at yahoo.com.au (Lew L) Date: Thu, 7 Aug 2008 08:29:33 +1000 Subject: [Rxtx] Sun's Comm API Documentation References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> Message-ID: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> As a matter of interest is the Sun Comm API documentation available somewhere? I have tried the Sun site but it seems to have been removed. Unless I have missed the documentation for RXTX? I javadocced the RXTX source but information (to me) is minimal. Somewhere I got the impression that the Sun Comm API docs is, or was, compatible with RXTX, what is the best docs to use in conjuntion with RXTX and where may the be available? Cheers Lew From rick_knight at rlknight.com Wed Aug 6 17:18:33 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:18:33 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A3149.4050306@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff I'm not sure if I posted this here or not, but when I try to build RXTX from source I get this install error... make all-am make[1]: Entering directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' make[1]: Nothing to be done for `all-am'. make[1]: Leaving directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 Can you tell me how to get past this error and get RXTX built and installed? Thanks, Rick From bboyes at systronix.com Wed Aug 6 17:40:12 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Wed, 06 Aug 2008 17:40:12 -0600 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: At 16:29 08/06/2008, Lew L wrote: >As a matter of interest is the Sun Comm API documentation available >somewhere? I have tried the Sun site but it seems to have been removed. It's in the file we have posted, link in prev email (sorry, in a huge hurry right now). Javadocs definitely there. >Unless I have missed the documentation for RXTX? I javadocced the RXTX >source but information (to me) is minimal. >Somewhere I got the impression that the Sun Comm API docs is, or was, >compatible with RXTX, what is the best docs to use in conjuntion with RXTX >and where may the be available? Yeah, this is one of my concerns/beefs. There is little documentation for RXTX and it isn't just the same as javaxcomm. I would be willing to help out writing docs for RXTX! Yes really... esp if we can fix the Bluetooth issues. best regards Bruce >Cheers >Lew > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx ------- WWW.SYSTRONIX.COM ---------- Real embedded Java and much more +1-801-534-1017 Salt Lake City, USA From rick_knight at rlknight.com Wed Aug 6 17:54:08 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:54:08 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A39A0.2090309@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff, I would like for my vendor to switch to rxtx 2.1. It would make things much easier for me. I'm not sure why he's still using the javax compatible code. He's a small operation. Re-writing the code to use gnu namespace sounds like a major overhaul. Was it? Thanks, Rick From tjarvi at qbang.org Wed Aug 6 21:35:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:35:12 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: >> >>> Jeff wrote: >>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>>> >>>> >>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things > much easier for me. I'm not sure why he's still using the javax > compatible code. He's a small operation. Re-writing the code to use gnu > namespace sounds like a major overhaul. Was it? > Hi Jeff, The changes are fairly mechanical. Imports need to change and any explicite use of the namespace needs to change such as catching an exception. The following script was made for maintaining rxtx 2.0 but can apply to other needs. It is in the contrib dir with rxtx source. #!/bin/sh # Don't use! :) # # Sat, 03 May 2003 16:45:08 Modifications from J?rg Weule # Create a ed-cmd for the change of one pattern # case $1 in gnu) X=g/javax_comm/s+javax_comm+gnu_io+g ;; javax) X=g/gnu_io/s+gnu_io+javax_comm+g ;; *) echo;echo;echo From the top rxtx directory run;echo;echo -e \\t./ChangePackage.sh gnu;echo -e \\t\\tor;echo -e \\t./ChangePackage.sh javax;echo;echo; exit 0 ;; esac # # ed will be used to keep the owner and mode of the files unchanged. # We have run the ed-script for the characters '.' '/' as well. # "tr _ $D" do the change. # find . -type f -a -print | grep -v $0 | (while read F ; do ( echo $X; echo $X| tr _ /; echo $X| tr _ .; echo w; echo q ) | ed $F 2>&1 >/dev/null done ) # # Now we do little changes at the Makefiles. Hope that all we need. # find . -name Makefile\* -a -print | (while read F ; do cat < References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: On Thu, 7 Aug 2008, Lew L wrote: > As a matter of interest is the Sun Comm API documentation available > somewhere? I have tried the Sun site but it seems to have been removed. > > Unless I have missed the documentation for RXTX? I javadocced the RXTX > source but information (to me) is minimal. > Somewhere I got the impression that the Sun Comm API docs is, or was, > compatible with RXTX, what is the best docs to use in conjuntion with RXTX > and where may the be available? > Hi Lew, The documentation on Sun's website is accurate. The changes that are problematic in 3.0 are on the backside which rxtx used to plug into. http://java.sun.com/products/javacomm/reference/api/index.html CommPortIdentifier may have some minor differences (judging by the authors notes). -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Aug 6 21:46:08 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:46:08 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > If javax.comm.properties is properly installed and you are using a 2.0 version of Sun's commapi with rxtx 2.0, you should not see the library attempt to load libSolarisSerialParallel.so. Sun CommAPI 3.0 will not work with any version of rxtx as it is hard coded to use the shared library. See the INSTALL file with rxtx-2.0 source for more help with the properties file. -- Trent Jarvi tjarvi at qbang.org From jlar310 at gmail.com Thu Aug 7 06:32:06 2008 From: jlar310 at gmail.com (Jeff) Date: Thu, 7 Aug 2008 07:32:06 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > Jeff wrote: >> >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >> wrote: >> >>> >>> Jeff wrote: >>> >>>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>> wrote: >>>> >>>> >>>> >>>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things much > easier for me. I'm not sure why he's still using the javax compatible code. > He's a small operation. Re-writing the code to use gnu namespace sounds like > a major overhaul. Was it? I found it quite easy. In fact, in order to accommodate the transition, I actually separated all of the code that deals directly with the Comm API or RXTX into a helper class. The helper class was then coded to use reflection to determine which library was available and then instantiate the necessary objects. No direct imports of either library are used. The main application just needs to get it's hands on the IO streams and need not deal directly with the libraries. Other programs may not be so simple... But this doesn't really help you unless your vendor forks over the source code... -- Jeff From rick_knight at rlknight.com Thu Aug 7 09:47:12 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Thu, 07 Aug 2008 08:47:12 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: <489B1900.10108@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >>> wrote: >>> >>> >>>> Jeff wrote: >>>> >>>> >>>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>>> copy of the comm.api and I've copied the library >>>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>>> into the proper places. When I try to run the application, I get this >>>>>> error... >>>>>> >>>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>>> /usr/lib/libSolarisSerialParallel.so: >>>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>>> little-endian (Possible cause: endianness mismatch) >>>>>> Caught java.lang.UnsatisfiedLinkError: >>>>>> >>>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>>> >>>>>> while loading driver com.sun.comm.SolarisDriver >>>>>> >>>>>> Is there a way around this error? >>>>>> >>>>>> >>>>>> >>>>> What host OS are you running? From your original post it looks like 32 >>>>> bit Linux. >>>>> >>>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>>> depending on the underlying hardware architecture as well. >>>>> >>>>> >>>>> >>>>> >>>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>>> >>>> >>>> >>> I don't think Sun did binary libraries for Linux in the 2.0 version. >>> Can someone with more historical experience than I confirm that? >>> >>> I recently tried to port a Comm API application from Solaris sparc to >>> Linux x86 and likewise could not get my hands on the binary libraries. >>> I eventually just re-wrote the code to use the gnu namespace packages >>> and rxtx 2.1. >>> >>> What I don't understand is why your application vendor does not >>> provide everything you need to run their software. >>> >>> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >>> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >>> /usr/java/default which is actually a softlink to >>> /usr/java/jre1.6.0_05. >>> >>> >>> >> Jeff, >> >> I would like for my vendor to switch to rxtx 2.1. It would make things much >> easier for me. I'm not sure why he's still using the javax compatible code. >> He's a small operation. Re-writing the code to use gnu namespace sounds like >> a major overhaul. Was it? >> > > I found it quite easy. In fact, in order to accommodate the > transition, I actually separated all of the code that deals directly > with the Comm API or RXTX into a helper class. The helper class was > then coded to use reflection to determine which library was available > and then instantiate the necessary objects. No direct imports of > either library are used. The main application just needs to get it's > hands on the IO streams and need not deal directly with the libraries. > Other programs may not be so simple... > > But this doesn't really help you unless your vendor forks over the > source code... > > Jeff, This may not help me directly, but I'm going to forward this thread to the vendor. I think he'll be open to making things work. Thanks again, Rick Knight From agusmunioz at gmail.com Thu Aug 7 16:39:51 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Thu, 7 Aug 2008 19:39:51 -0300 Subject: [Rxtx] How to send ack? Message-ID: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Hi, I'm still learning about serial communication and I have some doubts. I've got this question about how to do the following thing in rxtx. I have this hardware that connect to a PC using a serial port. These hardware receives data from a telephone line, proccess it, and then send it forward to the serial port. I've used a program named wincomm that shows what information is send it through the serial port and I have the nex behaviour: The hardware has a buffer where all data is stored, that cannot be sent it through the seria port. The program reads the first data send it by the hardware, and keep reading the same data always. There is a button in the application that says enable Ack, and when I click, then the hardware start to send all the stored information, and all the information is shown. I write a class, using rxtx that reads the serial port, and the same thing happens, it remains reading the same (first) data all the time. And I thing something like the enable Ack I'm missing. How can I do this enable Ack from my java code using rxtx? Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080807/e0a0f9a1/attachment-0007.html From ajmas at sympatico.ca Thu Aug 7 18:26:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 7 Aug 2008 20:26:41 -0400 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: <4BF42297-81E2-4BB8-A89F-1D43588379AE@sympatico.ca> On 6-Aug-08, at 19:40 , Bruce Boyes wrote: >> Unless I have missed the documentation for RXTX? I javadocced the >> RXTX >> source but information (to me) is minimal. >> Somewhere I got the impression that the Sun Comm API docs is, or was, >> compatible with RXTX, what is the best docs to use in conjuntion >> with RXTX >> and where may the be available? > > Yeah, this is one of my concerns/beefs. There is little documentation > for RXTX and it isn't just the same as javaxcomm. > > I would be willing to help out writing docs for RXTX! Yes really... > esp if we can fix the Bluetooth issues. If you want to contribute documentation then the best place to do that is the wiki. If there is anything missing or that could be improved on then please do so. If there are any points that you would like to see improved, for which you don't have the knowledge then ask on the mailing list for a volunteer. Andre From florianmanschwetus at gmx.de Fri Aug 8 03:04:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Fri, 08 Aug 2008 11:04:14 +0200 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Message-ID: <489C0C0E.2020401@gmx.de> Agustin Mu?oz schrieb: > Hi, I'm still learning about serial communication and I have some > doubts. I've got this question about how to do the following thing in rxtx. > I have this hardware that connect to a PC using a serial port. These > hardware receives data from a telephone line, proccess it, and then send > it forward to the serial port. I've used a program named wincomm that > shows what information is send it through the serial port and I have the > nex behaviour: > > The hardware has a buffer where all data is stored, that cannot be sent > it through the seria port. > The program reads the first data send it by the hardware, and keep > reading the same data always. > There is a button in the application that says enable Ack, and when I > click, then the hardware start to send all the stored information, and > all the information is shown. > > I write a class, using rxtx that reads the serial port, and the same > thing happens, it remains reading the same (first) data all the time. > And I thing something like the enable Ack I'm missing. > How can I do this enable Ack from my java code using rxtx? Afaik, a look at man ascii reveals: Okt Dez Hex Char 006 6 06 ACK So, i hope this will do the job: send(6); florian > > Thanks in advance > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/5b4965f8/attachment-0007.bin From agusmunioz at gmail.com Fri Aug 8 16:31:00 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 19:31:00 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <489C0C0E.2020401@gmx.de> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> Message-ID: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Hi Florian, thanks for the answer. By send(6) you mean to get the port OutputStream and write a 6? I try that but it didn't work. Any suggestion? Thanks On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < florianmanschwetus at gmx.de> wrote: > Agustin Mu?oz schrieb: > > Hi, I'm still learning about serial communication and I have some doubts. >> I've got this question about how to do the following thing in rxtx. >> I have this hardware that connect to a PC using a serial port. These >> hardware receives data from a telephone line, proccess it, and then send it >> forward to the serial port. I've used a program named wincomm that shows >> what information is send it through the serial port and I have the nex >> behaviour: >> >> The hardware has a buffer where all data is stored, that cannot be sent >> it through the seria port. >> The program reads the first data send it by the hardware, and keep reading >> the same data always. >> There is a button in the application that says enable Ack, and when I >> click, then the hardware start to send all the stored information, and all >> the information is shown. >> >> I write a class, using rxtx that reads the serial port, and the same thing >> happens, it remains reading the same (first) data all the time. And I thing >> something like the enable Ack I'm missing. >> How can I do this enable Ack from my java code using rxtx? >> > Afaik, a look at man ascii reveals: > Okt Dez Hex Char > 006 6 06 ACK > So, i hope this will do the job: > send(6); > > florian > >> >> Thanks in advance >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/7f3fba42/attachment-0006.html From agusmunioz at gmail.com Fri Aug 8 18:39:27 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 21:39:27 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Message-ID: <988288430808081739x7f9e7889id82591d5a9e2b4f6@mail.gmail.com> Ok, Florian, it works!! my problem was that I've been sending, through the OutputStream, the bytes of 6 as a string: out.write("6".getBytes()); but then I realized that you can write an int on an OuptuStream, so I tried that and It works: out.write(6); Thank you for the guidance!! On Fri, Aug 8, 2008 at 7:31 PM, Agustin Mu?oz wrote: > Hi Florian, thanks for the answer. By send(6) you mean to get the port > OutputStream and write a 6? > > I try that but it didn't work. > > Any suggestion? > > Thanks > > > On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < > florianmanschwetus at gmx.de> wrote: > >> Agustin Mu?oz schrieb: >> >> Hi, I'm still learning about serial communication and I have some doubts. >>> I've got this question about how to do the following thing in rxtx. >>> I have this hardware that connect to a PC using a serial port. These >>> hardware receives data from a telephone line, proccess it, and then send it >>> forward to the serial port. I've used a program named wincomm that shows >>> what information is send it through the serial port and I have the nex >>> behaviour: >>> >>> The hardware has a buffer where all data is stored, that cannot be sent >>> it through the seria port. >>> The program reads the first data send it by the hardware, and keep >>> reading the same data always. >>> There is a button in the application that says enable Ack, and when I >>> click, then the hardware start to send all the stored information, and all >>> the information is shown. >>> >>> I write a class, using rxtx that reads the serial port, and the same >>> thing happens, it remains reading the same (first) data all the time. And I >>> thing something like the enable Ack I'm missing. >>> How can I do this enable Ack from my java code using rxtx? >>> >> Afaik, a look at man ascii reveals: >> Okt Dez Hex Char >> 006 6 06 ACK >> So, i hope this will do the job: >> send(6); >> >> florian >> >>> >>> Thanks in advance >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/b918ab3d/attachment-0006.html From florianmanschwetus at gmx.de Sat Aug 9 00:45:43 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Sat, 09 Aug 2008 08:45:43 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4899667C.6010706@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> Message-ID: <489D3D17.9090209@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >> Florian Manschwetus wrote: >>> Ok, sounds fine for the receiving problem. >>> But why i have to wait after each byte when sending a command squence? >>> (the for loop in send command) >> >> Hi Florian, >> I'd imagine you probably don't! You could send all bytes in one go and >> RXTX would send them. The problem is most probably the other end: >> perhaps it has a really small buffer, some non-standard UART, or a >> crazy timing issue. If you attach a terminal to your output and send >> all the bytes of a command in one go they should appear no problem. >> >> Regards, >> Michael Erskine. >> > correct with a terminal on the other end it works, my idea was that this > basic baud has some influence. Could some one explain what it is for? > > Florian To make it more clear, my problem is that i can't use: outputStream.write(byte[]); => Beamer doesn't understand the sequence. (mostly no answer when he answers then *001) when i use this construct instead: for (int i = 0; i < command.length; i++) { this.outputStream.write(command[i]); try { Thread.sleep(25); } catch (InterruptedException e) { // TODO Auto-generated catch block e.printStackTrace(); } } it works nearly reliable. So what could it be? This Basic Baud is what exactly? Florian -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080809/692304ee/attachment-0006.bin From tjarvi at qbang.org Sat Aug 9 16:37:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Aug 2008 16:37:19 -0600 (MDT) Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489D3D17.9090209@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> <489D3D17.9090209@gmx.de> Message-ID: On Sat, 9 Aug 2008, Florian Manschwetus wrote: > Florian Manschwetus schrieb: >> Michael Erskine schrieb: >>> Florian Manschwetus wrote: >>>> Ok, sounds fine for the receiving problem. >>>> But why i have to wait after each byte when sending a command squence? >>>> (the for loop in send command) >>> >>> Hi Florian, >>> I'd imagine you probably don't! You could send all bytes in one go and >>> RXTX would send them. The problem is most probably the other end: perhaps >>> it has a really small buffer, some non-standard UART, or a crazy timing >>> issue. If you attach a terminal to your output and send all the bytes of a >>> command in one go they should appear no problem. >>> >>> Regards, >>> Michael Erskine. >>> >> correct with a terminal on the other end it works, my idea was that this >> basic baud has some influence. Could some one explain what it is for? >> >> Florian > To make it more clear, > my problem is that i can't use: > outputStream.write(byte[]); > => Beamer doesn't understand the sequence. (mostly no answer when he answers > then *001) > > when i use this construct instead: > > for (int i = 0; i < command.length; i++) { > this.outputStream.write(command[i]); > try { > Thread.sleep(25); > } catch (InterruptedException e) { > // TODO Auto-generated catch block > e.printStackTrace(); > } > } > > it works nearly reliable. > > So what could it be? This Basic Baud is what exactly? > I suspect you are using the 'moon protocol' and don't know it. RXTX enables this by default. The buffer on the other end is first in first out while reading. If the buffer is full, the bits are hand carried to the moon and burried. Then if the other side reads a couple bytes, two more bytes go into the buffer followed by more moon protocol. The resulting array of bytes the other side reads may appear to be scrambled until you go to the moon, get the bits and insert them in the right place. Flow control can prevent the default moon protocol and throttles the communiation by almost writing a byte at a time as need be. Hardware flow control is preferable but software flow control should also work. Read and write can appear to hang if the other side is not connected. This is why we don't enable them all the time. If you can't use flow control, you have to take care with the moon protocol and give the other side time to read. That is what your slower version of write is doing. -- Trent Jarvi tjarvi at qbang.org From rxtx at allenjb.me.uk Mon Aug 11 08:06:36 2008 From: rxtx at allenjb.me.uk (AllenJB) Date: Mon, 11 Aug 2008 15:06:36 +0100 Subject: [Rxtx] Disabling EV_RXFLAG Message-ID: <48A0476C.2090800@allenjb.me.uk> Hi all, I'm working with a device which does not use an EvtChar and need to disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an event mask of FD 01 00 00. The reference software I have uses FB 00 00 00. With the rxtx mask I get framing errors which I believe are caused when the EvtChar is received. Is there currently a way with rxtx (I've using rxtx from Java) to disable EV_RXFLAG? If not from Java, where would I start if I wanted to turn the EV_RXFLAG option off in the C code? I've had a grep of the rxtx source code, but I can't see where EV_RXFLAG is being set. Thanks in advance, AllenJB From tjarvi at qbang.org Mon Aug 11 14:17:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Aug 2008 14:17:27 -0600 (MDT) Subject: [Rxtx] Disabling EV_RXFLAG In-Reply-To: <48A0476C.2090800@allenjb.me.uk> References: <48A0476C.2090800@allenjb.me.uk> Message-ID: On Mon, 11 Aug 2008, AllenJB wrote: > Hi all, > > I'm working with a device which does not use an EvtChar and need to > disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an > event mask of FD 01 00 00. The reference software I have uses FB 00 00 > 00. With the rxtx mask I get framing errors which I believe are caused > when the EvtChar is received. > > Is there currently a way with rxtx (I've using rxtx from Java) to > disable EV_RXFLAG? > > If not from Java, where would I start if I wanted to turn the EV_RXFLAG > option off in the C code? I've had a grep of the rxtx source code, but I > can't see where EV_RXFLAG is being set. > > Thanks in advance, > > AllenJB Hi Allen, I'd look at termios.c::tcsetattr() and termios.c::FillDCB() -- Trent Jarvi tjarvi at qbang.org From superdadusa at gmail.com Tue Aug 12 13:57:32 2008 From: superdadusa at gmail.com (John Choi) Date: Tue, 12 Aug 2008 13:57:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. Message-ID: Hi all, Just let you all know I just start to learn Java. I have download the serial comm package and the source code from open source communities.. I was able to verify with the given message string via serial monitor. when the given message string sends to the serial port then the character return added to the end of string by default if I use "Hello World" however if I changed to something else other than "Hello, World" there is no character return add to the end of string. I thing the library download from rxtx.org has implemented for the special strings. I can do like "login\n" in the string message to make character return but I don't want to add this individual custom character for each command return in every static message string I send, Can any who have done this might help me? Basically, something like this,, Write and add function to the program write a command, Reads the respond from a serial device.. Function handles multiple messages, Write: "com open" Read: Welcome to my world" expected Write: "admin" Read: Password?, expected Write: "admin" Read: you are successfully login terminal, expected. And I need to add a separate function handler handles a character return add to the each command above. If anyone can help this I can do the reset? Thank you in advance, John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0002.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SerialIO.java Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0002.pl From Steffen.DETTMER at ingenico.com Wed Aug 13 02:16:38 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 13 Aug 2008 10:16:38 +0200 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: References: Message-ID: <20080813081638.GA25412@elberon.bln.de.ingenico.com> * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > I can do like "login\n" in the string message to make character > return but I don't want to add this individual custom character > for each command return in every static message string I send, and why not?! > Can any who have done this might help me? what's about with writing a small wrapper function adding the carriage return? However, this would be slow, because either you call write two times (very bad) or the string needs to be copied, \n appended and written (since you are using Java Performance probably isn't so critical). Personally I would write `"login\n"' and `username + "\n"' etc., because since it is part of the command it should be part of the command definition string. > Basically, something like this,, Write and add function to the program write > a command, Reads the respond from a serial device.. correctly reading a `line' is more difficult. If you cannot make assumptions about timeouts and/or you need to have low delay, you need to read byte wise. If you need to save CPU resources you might need to add some buffering layer that you can read byte-wise but that is reading blockwise with some small timeout (lets say for serial lines something around byte transmission time times three or so). > /* > * To change this template, choose Tools | Templates > * and open the template in the editor. > */ :) > package joliba; > > /** > * > * @author root > */ :) > // derived from SUN's examples in the javax.comm package > import java.io.*; > import java.util.*; > //import javax.comm.*; // for SUN's serial/parallel port libraries > import gnu.io.*; // for rxtxSerial library > > public class SerialIO implements Runnable, SerialPortEventListener { > static CommPortIdentifier portId; > static CommPortIdentifier saveportId; > static Enumeration portList; > InputStream inputStream; > SerialPort serialPort; > Thread readThread; You need a thread for your synchronous RPC-style protocol? > static String messageString = "Hello, world!"; > static OutputStream outputStream; > static boolean outputBufferEmptyFlag = false; > > public static void main(String[] args) { > boolean portFound = false; > String defaultPort; > > // determine the name of the serial port on several operating systems > String osname = System.getProperty("os.name","").toLowerCase(); > if ( osname.startsWith("windows") ) { > // windows > defaultPort = "COM1"; > } else if (osname.startsWith("linux")) { > // linux > defaultPort = "/dev/ttyS0"; > } else if ( osname.startsWith("mac") ) { > // mac > defaultPort = "????"; > } else { > System.out.println("Sorry, your operating system is not supported"); > return; > } Is such a construction recommended? Isn't there some abstraction (like COM1 working on any platform)? [...] > try { > // activate the OUTPUT_BUFFER_EMPTY notifier > serialPort.notifyOnOutputEmpty(true); > } catch (Exception e) { > System.out.println("Error setting event notification"); > System.out.println(e.toString()); > System.exit(-1); > } I doubt that -1 is defined, probably some 127 or so would be the result, maybe better simply `throw e'? > public void writetoport() { > System.out.println("Writing \""+messageString+"\" to "+serialPort.getName()); > try { > // write string to serial port > outputStream.write(messageString.getBytes()); > } catch (IOException e) {} > } maybe something like /** * Writes the given output string and an additional carriage * return to the current outputStream. */ public void writeStringToPort( /** The output string (without CR). */ String output ) throws IOException { String outputLine = output + "\n"; outputStream.write(outputLine.getBytes()); } ? > > public SerialIO() { > // initalize serial port > try { > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > } catch (PortInUseException e) {} if the port is in use, you continue? Wonder that this works in Java, I would assume serialPort beeing uninitialized which AFAIK is an error in Java. > try { > inputStream = serialPort.getInputStream(); > } catch (IOException e) {} > > try { > serialPort.addEventListener(this); > } catch (TooManyListenersException e) {} > > // activate the DATA_AVAILABLE notifier > serialPort.notifyOnDataAvailable(true); > > try { > // set port parameters > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > } catch (UnsupportedCommOperationException e) {} > > // start the read thread > readThread = new Thread(this); > readThread.start(); > > } I think in all those exception cases you can abort, because it is unlikely that ignoring those errors allow a successful continuation, so in this case maybe it would be better to add a throw clause to the method. > public void run() { > // first thing in the thread, we initialize the write operation > initwritetoport(); > try { > while (true) { > // write string to port, the serialEvent will read it > writetoport(); > Thread.sleep(1000); > } > } catch (InterruptedException e) {} > } Does this make sense? Your `SimpleReadApp' writes one and the same string each second? > public void serialEvent(SerialPortEvent event) { > switch (event.getEventType()) { > case SerialPortEvent.BI: > case SerialPortEvent.OE: > case SerialPortEvent.FE: > case SerialPortEvent.PE: > case SerialPortEvent.CD: > case SerialPortEvent.CTS: > case SerialPortEvent.DSR: > case SerialPortEvent.RI: > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > break; > case SerialPortEvent.DATA_AVAILABLE: > // we get here if data has been received > byte[] readBuffer = new byte[20]; > try { > // read data > while (inputStream.available() > 0) { > int numBytes = inputStream.read(readBuffer); > } > // print data > String result = new String(readBuffer); > System.out.println("Read: "+result); > } catch (IOException e) {} I doubt that this is correct. I would assume you will get a 20 bytes result always, if more bytes would be available they would be printed in a second line but if less bytes are read I'd assume that the buffer/result contains zero bytes from implicite readBuffer contents initialisation (zero is no string terminator in Java AFAIK). > break; > } > } > } oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From florianmanschwetus at gmx.de Wed Aug 13 06:09:31 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 13 Aug 2008 14:09:31 +0200 Subject: [Rxtx] someone has seen such errors? Message-ID: <48A2CEFB.90007@gmx.de> I mean my communication mostly works, but it is far from perfect could this be the reason? Florian Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/949b9947/attachment-0001.bin From superdadusa at gmail.com Wed Aug 13 08:40:32 2008 From: superdadusa at gmail.com (John Choi) Date: Wed, 13 Aug 2008 08:40:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: <20080813081638.GA25412@elberon.bln.de.ingenico.com> References: <20080813081638.GA25412@elberon.bln.de.ingenico.com> Message-ID: Thank you so much Steffen and I will try that suggestion. John On 8/13/08, Steffen DETTMER wrote: > > * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > > I can do like "login\n" in the string message to make character > > return but I don't want to add this individual custom character > > for each command return in every static message string I send, > > and why not?! > > > Can any who have done this might help me? > > what's about with writing a small wrapper function adding the > carriage return? > However, this would be slow, because either you call write two > times (very bad) or the string needs to be copied, \n appended > and written (since you are using Java Performance probably isn't > so critical). > > Personally I would write `"login\n"' and `username + "\n"' etc., > because since it is part of the command it should be part of the > command definition string. > > > Basically, something like this,, Write and add function to the program > write > > a command, Reads the respond from a serial device.. > > correctly reading a `line' is more difficult. If you cannot make > assumptions about timeouts and/or you need to have low delay, you > need to read byte wise. If you need to save CPU resources you > might need to add some buffering layer that you can read > byte-wise but that is reading blockwise with some small timeout > (lets say for serial lines something around byte transmission > time times three or so). > > > /* > > * To change this template, choose Tools | Templates > > * and open the template in the editor. > > */ > > :) > > > package joliba; > > > > /** > > * > > * @author root > > */ > > :) > > > // derived from SUN's examples in the javax.comm package > > import java.io.*; > > import java.util.*; > > //import javax.comm.*; // for SUN's serial/parallel port libraries > > import gnu.io.*; // for rxtxSerial library > > > > public class SerialIO implements Runnable, SerialPortEventListener { > > static CommPortIdentifier portId; > > static CommPortIdentifier saveportId; > > static Enumeration portList; > > InputStream inputStream; > > SerialPort serialPort; > > Thread readThread; > > You need a thread for your synchronous RPC-style protocol? > > > static String messageString = "Hello, world!"; > > static OutputStream outputStream; > > static boolean outputBufferEmptyFlag = false; > > > > public static void main(String[] args) { > > boolean portFound = false; > > String defaultPort; > > > > // determine the name of the serial port on several operating > systems > > String osname = System.getProperty("os.name","").toLowerCase(); > > if ( osname.startsWith("windows") ) { > > // windows > > defaultPort = "COM1"; > > } else if (osname.startsWith("linux")) { > > // linux > > defaultPort = "/dev/ttyS0"; > > } else if ( osname.startsWith("mac") ) { > > // mac > > defaultPort = "????"; > > } else { > > System.out.println("Sorry, your operating system is not > supported"); > > return; > > } > > Is such a construction recommended? Isn't there some abstraction > (like COM1 working on any platform)? > > [...] > > try { > > // activate the OUTPUT_BUFFER_EMPTY notifier > > serialPort.notifyOnOutputEmpty(true); > > } catch (Exception e) { > > System.out.println("Error setting event notification"); > > System.out.println(e.toString()); > > System.exit(-1); > > } > > I doubt that -1 is defined, probably some 127 or so would be the > result, maybe better simply `throw e'? > > > public void writetoport() { > > System.out.println("Writing \""+messageString+"\" to > "+serialPort.getName()); > > try { > > // write string to serial port > > outputStream.write(messageString.getBytes()); > > } catch (IOException e) {} > > } > > maybe something like > > /** > * Writes the given output string and an additional carriage > * return to the current outputStream. > */ > public void > writeStringToPort( > /** The output string (without CR). */ > String output > ) throws IOException > { > String outputLine = output + "\n"; > outputStream.write(outputLine.getBytes()); > } > > ? > > > > > public SerialIO() { > > // initalize serial port > > try { > > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > > } catch (PortInUseException e) {} > > if the port is in use, you continue? Wonder that this works in > Java, I would assume serialPort beeing uninitialized which AFAIK > is an error in Java. > > > try { > > inputStream = serialPort.getInputStream(); > > } catch (IOException e) {} > > > > try { > > serialPort.addEventListener(this); > > } catch (TooManyListenersException e) {} > > > > // activate the DATA_AVAILABLE notifier > > serialPort.notifyOnDataAvailable(true); > > > > try { > > // set port parameters > > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > } catch (UnsupportedCommOperationException e) {} > > > > // start the read thread > > readThread = new Thread(this); > > readThread.start(); > > > > } > > I think in all those exception cases you can abort, because it is > unlikely that ignoring those errors allow a successful > continuation, so in this case maybe it would be better to add a > throw clause to the method. > > > public void run() { > > // first thing in the thread, we initialize the write operation > > initwritetoport(); > > try { > > while (true) { > > // write string to port, the serialEvent will read it > > writetoport(); > > Thread.sleep(1000); > > } > > } catch (InterruptedException e) {} > > } > > Does this make sense? Your `SimpleReadApp' writes one and the > same string each second? > > > public void serialEvent(SerialPortEvent event) { > > switch (event.getEventType()) { > > case SerialPortEvent.BI: > > case SerialPortEvent.OE: > > case SerialPortEvent.FE: > > case SerialPortEvent.PE: > > case SerialPortEvent.CD: > > case SerialPortEvent.CTS: > > case SerialPortEvent.DSR: > > case SerialPortEvent.RI: > > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > > break; > > case SerialPortEvent.DATA_AVAILABLE: > > // we get here if data has been received > > byte[] readBuffer = new byte[20]; > > try { > > // read data > > while (inputStream.available() > 0) { > > int numBytes = inputStream.read(readBuffer); > > } > > // print data > > String result = new String(readBuffer); > > System.out.println("Read: "+result); > > } catch (IOException e) {} > > I doubt that this is correct. I would assume you will get a 20 > bytes result always, if more bytes would be available they would > be printed in a second line but if less bytes are read I'd assume > that the buffer/result contains zero bytes from implicite > readBuffer contents initialisation (zero is no string terminator > in Java AFAIK). > > > break; > > } > > } > > } > > oki, > > Steffen > > About Ingenico Throughout the world businesses rely on Ingenico for secure > and expedient electronic transaction acceptance. Ingenico products leverage > proven technology, established standards and unparalleled ergonomics to > provide optimal reliability, versatility and usability. This comprehensive > range of products is complemented by a global array of services and > partnerships, enabling businesses in a number of vertical sectors to accept > transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged > information. If you are not the addressee or authorized to receive this for > the addressee, you must not use, copy, disclose or take any action based on > this message or any information herein. If you have received this message in > error, please advise the sender immediately by reply e-mail and delete this > message. Thank you for your cooperation. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/73c4135c/attachment-0001.html From rick_knight at rlknight.com Mon Aug 4 13:25:10 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Mon, 04 Aug 2008 12:25:10 -0700 Subject: [Rxtx] Sun's Comm API? Message-ID: <48975796.4010600@rlknight.com> I have an application that requires the javax compatible version of RXTX and Sun's comm api. I've been able to download and extract the version of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api anywhere. Can someone tell me where I can find it? Or maybe send me a copy? Also, when I try to build RXTX, configure and make complete successfully but make install failes with this error libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 I've never come accross this error before. How can I get past it? Thanks, Rick From bboyes at systronix.com Mon Aug 4 19:10:01 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:10:01 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48975796.4010600@rlknight.com> References: <48975796.4010600@rlknight.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/cb9c6167/attachment-0011.html From bboyes at systronix.com Mon Aug 4 19:12:37 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:12:37 -0600 Subject: [Rxtx] Towards an RXTX release - CSR BT/USB chipset In-Reply-To: <488FB7E7.8000802@gmail.com> References: <460801A4097E3D4CA04CC64EE648584806C56CF0@ism-mail03.corp.ad.wrs.com> <13557-75390@sneakemail.com> <20980-23424@sneakemail.com> <488FB7E7.8000802@gmail.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/52236088/attachment-0011.html From tjarvi at qbang.org Mon Aug 4 19:42:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 19:42:21 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: On Mon, 4 Aug 2008, Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: > I have an application that requires the javax compatible > version of RXTX > and Sun's comm api. I've been able to download and extract > the version > of RXTX that I need (2.0-7pre2) but I can't find Sun's camm > api > anywhere. Can someone tell me where I can find it? Or maybe > send me a > > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm port > support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have just > a ZIP with only the .class JAR file - no source or docs), has a readme > with these comments: > > This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release.? The 2.0.3 release itself is > no longer distributed.? comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project.? The RxTx project (http://www.rxtx.org ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org) was opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support.? Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins.? Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > ? > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > I hope that is helpful! > It would be nice to work with Sun to resolve those longstanding issues. But it may not be practical unless the process goes as fast and painless as the grandfathering of commapi did. Another option may be the old kaffe extensions that moved to gnu classpathx. These don't have the native libraries but should provide the 2.0 interface and the javax.comm.properties mechansim for SPI. http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Mon Aug 4 20:23:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Mon, 04 Aug 2008 20:23:57 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4897B9BD.5070809@ergotech.com> Has there been any work/would it be possible, to layer a javacomm look-alike on top of the GNU code? The goal is not to move the javax code forward, but to emulate the "legacy" javax packages for people who still need this. Jim Trent Jarvi wrote: > On Mon, 4 Aug 2008, Bruce Boyes wrote: > >> At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible >> version of RXTX >> and Sun's comm api. I've been able to download and extract >> the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm >> api >> anywhere. Can someone tell me where I can find it? Or maybe >> send me a >> >> >> javaxcomm has had a sort of on-again off-again history. The windoze >> version has been languishing for years (literally) but there are newer >> versions for other OS's. >> >> We try to keep links on one of our help pages current: >> http://www.practicalembeddedjava.com/tools/javatools_list.html >> which gets you to here: >> http://java.sun.com/products/javacomm/ >> where it says in fact they no longer even support Windows and Mac: >> "Implementations of the API are currently available for Solaris SPARC, >> Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so >> someone could support it. But I guess that's part of the reason RXTX >> exists! >> >> So one of Sun's own products, SunSPOT, has to use RXTX to get comm port >> support. >> >> The version we use is 2.0 from 11/15/1998. I have posted it on our >> website, which is within the terms of the license agreement contained >> therein (as I understand it). >> >> The last version of javaxcomm for Windows, 2.0.3, (for which I have just >> a ZIP with only the .class JAR file - no source or docs), has a readme >> with these comments: >> >> This distribution contains the comm.jar file original part >> of the COMMAPI 2.0.3 release. The 2.0.3 release itself is >> no longer distributed. comm.jar, which contains the comm >> API java class files (eg. Sun's binary implementation of the >> interface classes), is being made available, unsupported, >> with no obligation to fix bugs, at the request of the RXTX >> project. The RxTx project (http://www.rxtx.org ), uses the >> comm.jar class files, but provides their own native library >> components to provide support for other platforms. >> >> The 2.0.3 comm.jar is being provided in this way because >> as of COMMAPI 3.x, the java binary implementation forked and >> became incompatible with the RxTx project's native code. >> Due to the lack of a clear business case, and to resource >> constraints, no additional resources are being >> provided to provide an alternative engineering solution >> at the time of writing. >> >> RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: >> >> Ultimately the COMMAPI would be better served if a Java >> Community Process JSR (http://www.jcp.org) was opened and >> the COMMAPI was rearchitected to provide a more pluggable >> framework to improve cross-platform support. Such an >> architecture would embody a better defined and better >> documented SPI interface, including a way for comm. ports >> to be revealed to the client application through the API >> via platform-aware plugins. Similarly, native code used >> to access comm port in general could be handled more >> flexibly using a plugin model, whereby on any platform, >> multiple native modules could be in use simultaneously. >> >> Since there are now various ways serial ports can be implemented >> and accessed, modular comm. port JNI native libraries would be >> of benefit insofar as removing the burden of over-generalization >> from any single native component, or inversely, by relieving the >> implicit constraint that comm. drivers be accessed only via a >> monolithic mechanism, such as the UNIX vnode interface. >> >> paul.klissner at sun.com >> 6/10/06 >> >> I hope that is helpful! >> > > It would be nice to work with Sun to resolve those longstanding issues. > But it may not be practical unless the process goes as fast and painless > as the grandfathering of commapi did. > > Another option may be the old kaffe extensions that moved to gnu > classpathx. These don't have the native libraries but should provide > the 2.0 interface and the javax.comm.properties mechansim for SPI. > > http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Mon Aug 4 21:09:15 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 21:09:15 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? Message-ID: Hi Jim, I will not step into the javax.comm namespace without Sun's explicite permission. I fully understand the pain point you are trying to address. In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm Linux) - which remains an integral part of rxtx. At the time it was a win for Sun and rxtx. The Sun commapi license is/was fairly clear that rxtx should not step into that namespace. It made sense as Sun was active in that space and rxtx may go into another namespace - it was an experiment in working with Sun. This may sound silly looking at something that happened almost 10 years ago. In a community of respect which Sun helped create, there is no question about what to do. I hope eventually Sun will step up and do a right thing too. I agree that this is hurting the API more than helping it. There are also questions about how to replace the API in the long term which includes HID support which isn't going well so far. Others that can't even look at Sun's javax.comm today and can look at Kaffe's contribution to classpathx can easily work around such restrictions. On Mon, 4 Aug 2008, Jim Redman wrote: > Has there been any work/would it be possible, to layer a javacomm > look-alike on top of the GNU code? > > The goal is not to move the javax code forward, but to emulate the > "legacy" javax packages for people who still need this. > > Jim > > Trent Jarvi wrote: >> >> It would be nice to work with Sun to resolve those longstanding issues. >> But it may not be practical unless the process goes as fast and painless >> as the grandfathering of commapi did. >> >> Another option may be the old kaffe extensions that moved to gnu >> classpathx. These don't have the native libraries but should provide >> the 2.0 interface and the javax.comm.properties mechansim for SPI. >> >> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From florianmanschwetus at gmx.de Tue Aug 5 05:04:46 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 13:04:46 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: References: <48971C1F.9020806@gmx.de> Message-ID: <489833CE.1040801@gmx.de> Just look at sendCommand in this method I have to place a Thread.sleep(20) after each byte send to get working. Even the event based receive doesn't work fine but this could be may stupidness. The specifikation document (it is on the last pages of the manual) for the beamer could be found on: http://www.optoma.co.uk/support.aspx Florian Manschwetus Trent Jarvi schrieb: > > Hi Florian > > Sorry for the top post in advance. I worry you may not see my answer > under all your code :) > > I have not received this email before. This is 500k of code which I > don't have time to read. I can spend about 5 min on each hobby email > and still get to work in the morning. I have a couple suggestions for > how to get an answer. > > First, cut out your comments and extra code so you can demonstrate the > question (I might even glance and see what is wrong then). Don't go for > a working final product. Isolate the problem using a simple program and > then ask with that as an example. If I did what you just did, I'd have > to post 3/4 of a million lines of code :) > > Second, join the rxtx mail-list and ask there. This will give you 100x > more eyes. I'll also read and try to follow. > > -- > taj > > > > On Mon, 4 Aug 2008, Florian Manschwetus wrote: > >> It could be that my university account is blocked by filters so >> resending from here. >> >> >> Topic is to control Optoma HD80 beamer using rs232 serial chat. >> This code is able to detect power state and switch the beamer on / off. >> connected is the beamer using a digitus usb 2.0 serial adapter with an >> FT232 USB-Serial adapter the systems architecture is amd64. >> >> Please take a look in the sendCommand routine i have to place theire >> those Thread.sleep to get it working. >> Now the question is this correct or is there a better way to get this >> working correctly? >> >> In the javadoc coming with the install i found this: >> setBaudBase >> >> public boolean setBaudBase(int BaudBase) >> throws UnsupportedCommOperationException, >> java.io.IOException >> >> Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 >> before using. >> >> could this explain the error? >> I attached my java source and the protocol description for the beamer >> (available on vendor website). >> >> thx, >> Florian Manschwetus >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: TestRS232.java Type: text/x-java Size: 9143 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0022.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0023.bin From michael.erskine at ketech.com Tue Aug 5 05:53:49 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Tue, 5 Aug 2008 12:53:49 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489833CE.1040801@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> > Just look at sendCommand in this method I have to place a > Thread.sleep(20) after each byte send to get working. Even the event > based receive doesn't work fine but this could be may stupidness. Hi Florian, Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. Regards, Michael Erskine. From florianmanschwetus at gmx.de Tue Aug 5 07:28:15 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:28:15 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> Message-ID: <4898556F.8000208@gmx.de> Michael Erskine schrieb: >> Just look at sendCommand in this method I have to place a >> Thread.sleep(20) after each byte send to get working. Even the event >> based receive doesn't work fine but this could be may stupidness. > > Hi Florian, > > Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. > > Regards, > Michael Erskine. > Ok, sounds fine for the receiving problem. But why i have to wait after each byte when sending a command squence? (the for loop in send command) Florian > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/284f350c/attachment-0010.bin From florianmanschwetus at gmx.de Tue Aug 5 07:44:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:44:14 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <4898592E.2020908@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >>> Just look at sendCommand in this method I have to place a >>> Thread.sleep(20) after each byte send to get working. Even the event >>> based receive doesn't work fine but this could be may stupidness. >> >> Hi Florian, >> >> Yes, naturally you'll have to wait for a response from the other end. >> Why not wait for notification from the event thread perhaps using a >> BlockingDeque rather than your LinkedList. Generally I >> try to decouple all input and output streams: in your case your >> application is operating synchronously like the "expect" program >> (http://expect.nist.gov/) so waits (or timeouts) will need to be >> factored in. >> >> Regards, >> Michael Erskine. >> > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) > > Florian Furthermore there is this basic baud with this confusing javadoc entry: public boolean setBaudBase(int BaudBase) throws UnsupportedCommOperationException, java.io.IOException Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 before using. maybe this could explain something Florian >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/006c7425/attachment-0010.bin From jredman at ergotech.com Tue Aug 5 09:13:36 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 05 Aug 2008 09:13:36 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: Message-ID: <48986E20.3060104@ergotech.com> Trent, So two issues: 1) Technically I'm still not sure how easy/practical a layer would be. The problems are always classes like listeners, and wrapping returns of gnu.io classes. I really see it as a "delegate" type of concept. Any thoughts or ideas of the practicality of this approach? The idea is not to modify RXTX. 2) Javax. The javax namespace does seem to be in widespread use outside of Sun (the same is true for the java namespace). The classpath extensions, or some other location, should be interested in a JavaComm implementation even if it does have dependencies on RXTX. Would you have any philosophical objection to an approach like that? Of course, I suspect it might be better if someone with that authority at Sun would admit that the javax namespace is already in the wild and that there is no problem with it being used within RXTX. Jim Trent Jarvi wrote: > Hi Jim, > > I will not step into the javax.comm namespace without Sun's explicite > permission. I fully understand the pain point you are trying to address. > > In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm > Linux) - which remains an integral part of rxtx. At the time it was a win for > Sun and rxtx. > > The Sun commapi license is/was fairly clear that rxtx should not step into that > namespace. It made sense as Sun was active in that space and rxtx may go into > another namespace - it was an experiment in working with Sun. > > This may sound silly looking at something that happened almost 10 years ago. > In a community of respect which Sun helped create, there is no question about > what to do. I hope eventually Sun will step up and do a right thing too. > > I agree that this is hurting the API more than helping it. There are also > questions about how to replace the API in the long term which includes HID > support which isn't going well so far. > > Others that can't even look at Sun's javax.comm today and can look at Kaffe's > contribution to classpathx can easily work around such restrictions. > > On Mon, 4 Aug 2008, Jim Redman wrote: > >> Has there been any work/would it be possible, to layer a javacomm >> look-alike on top of the GNU code? >> >> The goal is not to move the javax code forward, but to emulate the >> "legacy" javax packages for people who still need this. >> >> Jim >> >> Trent Jarvi wrote: >>> It would be nice to work with Sun to resolve those longstanding issues. >>> But it may not be practical unless the process goes as fast and painless >>> as the grandfathering of commapi did. >>> >>> Another option may be the old kaffe extensions that moved to gnu >>> classpathx. These don't have the native libraries but should provide >>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>> >>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From sandeep at genevasoftech.com Tue Aug 5 11:18:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Tue, 05 Aug 2008 22:48:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <48988B6C.5080409@genevasoftech.com> Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. *-- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/ad20f1cb/attachment-0010.html From Martin.Oberhuber at windriver.com Tue Aug 5 13:30:17 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Tue, 5 Aug 2008 21:30:17 +0200 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Sandeep, shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on Sol7 but I've successfully run it on Sol9 and Sol10. Or is your request really about a native 64bit variant? I'm afraid that then you're out of luck since I think that quite a bit of RXTX is not yet ready for 64 bit. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Sandeep Kumar K Sent: Tuesday, August 05, 2008 7:19 PM To: rxtx at qbang.org Subject: [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so for Solaris 9 Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. -- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/81b7f988/attachment-0010.html From tjarvi at qbang.org Tue Aug 5 22:38:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 22:38:34 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 5 Aug 2008, Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built > on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid that > then > you're out of luck since I think that quite a bit of RXTX is not yet > ready > for 64 bit. > While rxtx-2.1-7 probably has problems, The CVS code should be OK for 64 bit Solaris. If it isn't, let me know and I'll find which patch is missing. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Aug 5 23:13:00 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 23:13:00 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48986E20.3060104@ergotech.com> References: <48986E20.3060104@ergotech.com> Message-ID: On Tue, 5 Aug 2008, Jim Redman wrote: > Trent, > > So two issues: > > 1) Technically I'm still not sure how easy/practical a layer would be. The > problems are always classes like listeners, and wrapping returns of gnu.io > classes. I really see it as a "delegate" type of concept. Any thoughts or > ideas of the practicality of this approach? The idea is not to modify RXTX. I have not put too much thought into this. I assume you want what rxtx 2.0 provided to tie into javax.comm implementations. More classes could be added to rxtx 2.1-7 for SPI support. Maintaining rxtx-2.0 could also be handed to someone if they like. > > 2) Javax. The javax namespace does seem to be in widespread use outside of > Sun (the same is true for the java namespace). The classpath extensions, or > some other location, should be interested in a JavaComm implementation even > if it does have dependencies on RXTX. Would you have any philosophical > objection to an approach like that? > No problems. Classpathx would be a possible place to do it. I'd suggest thinking twice about what this involves in practical terms. You would be wanting to revive the 2.0 API while Sun is at 3.0 and grandfathering the JSR. This undermines the main reason (established api) for using the javax.comm namespace and does not leave such a project in a good position. The only win I see here is maintaining support for applications that can't migrate namespaces. Not that that isn't important. At some point it is going to be less work to just edit the bytecode :) Such a javax.comm effort would also be signing up new projects that decided to use the work up for concerns they probably will not understand or expect. That probably isn't a good path to facilitate for new projects at this time. We will put a good faith effort to work well with others but keep in mind the project has limited bandwidth for such efforts. > Of course, I suspect it might be better if someone with that authority at Sun > would admit that the javax namespace is already in the wild and that there is > no problem with it being used within RXTX. > > Jim > > Trent Jarvi wrote: >> Hi Jim, >> >> I will not step into the javax.comm namespace without Sun's explicite >> permission. I fully understand the pain point you are trying to address. >> >> In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java >> Comm Linux) - which remains an integral part of rxtx. At the time it was a >> win for Sun and rxtx. >> >> The Sun commapi license is/was fairly clear that rxtx should not step into >> that namespace. It made sense as Sun was active in that space and rxtx may >> go into another namespace - it was an experiment in working with Sun. >> >> This may sound silly looking at something that happened almost 10 years >> ago. In a community of respect which Sun helped create, there is no >> question about what to do. I hope eventually Sun will step up and do a >> right thing too. >> >> I agree that this is hurting the API more than helping it. There are also >> questions about how to replace the API in the long term which includes HID >> support which isn't going well so far. >> >> Others that can't even look at Sun's javax.comm today and can look at >> Kaffe's contribution to classpathx can easily work around such >> restrictions. >> >> On Mon, 4 Aug 2008, Jim Redman wrote: >> >>> Has there been any work/would it be possible, to layer a javacomm >>> look-alike on top of the GNU code? >>> >>> The goal is not to move the javax code forward, but to emulate the >>> "legacy" javax packages for people who still need this. >>> >>> Jim >>> >>> Trent Jarvi wrote: >>>> It would be nice to work with Sun to resolve those longstanding issues. >>>> But it may not be practical unless the process goes as fast and painless >>>> as the grandfathering of commapi did. >>>> >>>> Another option may be the old kaffe extensions that moved to gnu >>>> classpathx. These don't have the native libraries but should provide >>>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>>> >>>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From sandeep at genevasoftech.com Wed Aug 6 00:03:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Wed, 06 Aug 2008 11:33:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: <48993EB8.30107@genevasoftech.com> Thank you Mr. Martin for your suggestion. The native file which is given in rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am getting the following error . Any suggestions to solve this issue. I am using Solaris SPARC 64 bit machine. ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) thrown while loading gnu.io.RXTXCommDriver Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(Unknown Source) at java.lang.ClassLoader.loadLibrary(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) at com.ReadFromModem.main(ReadFromModem.java:84) * * *Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid > that then > you're out of luck since I think that quite a bit of RXTX is not yet ready > for 64 bit. > > Cheers, > -- > *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > ------------------------------------------------------------------------ > *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On > Behalf Of *Sandeep Kumar K > *Sent:* Tuesday, August 05, 2008 7:19 PM > *To:* rxtx at qbang.org > *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so > for Solaris 9 > > Hi, > > Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 > bit machine. The librxtxSerial.so given in website is for Solaris 8. > > *-- > > Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/1e920343/attachment-0010.html From tjarvi at qbang.org Wed Aug 6 00:21:42 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 00:21:42 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <48993EB8.30107@genevasoftech.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> <48993EB8.30107@genevasoftech.com> Message-ID: Hi Sandeep You may be out of luck unless you can compile the 2.1 src in CVS (requires gnu make and gcc). But you could try the ToyBox(R)(TM) which is a collection of WiLdLy untested cross compiled 2.1-7 binaries covering everything from the ibm z series to embeded arm/ppc. To give an idea how poorly these are tested, I don't even know if z series machines have a serial port. ftp://www.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Solaris They should at least match the binary types. Actually, I think if you use the rxtx jar from CVS with that file, it should 'work' as the fix for 64 bits was in java not the native code. You could just cd rxtx*/src; javac *.java then jar -cf RXTXcomm.jar `find -name \*.class` to create the hybrid which will complain about version information a bit. On Wed, 6 Aug 2008, Sandeep Kumar K wrote: > Thank you Mr. Martin for your suggestion. The native file which is given in > rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am > getting the following error . > Any suggestions to solve this issue. > I am using Solaris SPARC 64 bit machine. > > ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar > java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 > (Possible cause: architecture word > width mismatch) thrown while loading gnu.io.RXTXCommDriver > Exception in thread "main" java.lang.UnsatisfiedLinkError: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF > class: ELFCLASS64 (Possible cause: > architecture word width mismatch) > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(Unknown Source) > at java.lang.ClassLoader.loadLibrary(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > at com.ReadFromModem.main(ReadFromModem.java:84) > > * > * > > *Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > > > Oberhuber, Martin wrote: >> Sandeep, >> shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse >> variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on >> Sol7 but I've successfully run it on Sol9 and Sol10. >> Or is your request really about a native 64bit variant? I'm afraid that >> then >> you're out of luck since I think that quite a bit of RXTX is not yet ready >> for 64 bit. >> Cheers, >> -- >> *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> ------------------------------------------------------------------------ >> *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On >> Behalf Of *Sandeep Kumar K >> *Sent:* Tuesday, August 05, 2008 7:19 PM >> *To:* rxtx at qbang.org >> *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so >> for Solaris 9 >> >> Hi, >> >> Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 >> bit machine. The librxtxSerial.so given in website is for Solaris 8. >> >> *-- >> Thanks & Regards >> >> Sandeep Kumar K >> Sr. Software Engineer >> Geneva Software Technologies >> Whitefield, Bangalore >> Mob : 9880193454* >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> From michael.erskine at ketech.com Wed Aug 6 01:39:28 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 6 Aug 2008 08:39:28 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Florian Manschwetus wrote: > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) Hi Florian, I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. Regards, Michael Erskine. From florianmanschwetus at gmx.de Wed Aug 6 02:53:16 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 06 Aug 2008 10:53:16 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Message-ID: <4899667C.6010706@gmx.de> Michael Erskine schrieb: > Florian Manschwetus wrote: >> Ok, sounds fine for the receiving problem. >> But why i have to wait after each byte when sending a command squence? >> (the for loop in send command) > > Hi Florian, > I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. > > Regards, > Michael Erskine. > correct with a terminal on the other end it works, my idea was that this basic baud has some influence. Could some one explain what it is for? Florian > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/c2b4fa84/attachment-0010.bin From rick_knight at rlknight.com Wed Aug 6 13:01:07 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:01:07 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F4F3.3020707@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > I have an application (Readerware) that uses RXTX with Javax to access the serial port. This used to work fine under previous Linux' and Java, but something has changed, I assume with Java itself , that is causing the application to fail with a link error. The application is not able to find librxtxSerialParallel.so. RXTX supplies librxtxSerial.so and librxtxParallel.so, but not librxtxSerialParallel.so. Where can I get librxtxSerialParallel.so, or do I need it? Is something else causing the lib to not be found? Thanks, Rick Knight From rick_knight at rlknight.com Wed Aug 6 13:17:55 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:17:55 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F8E3.5060400@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Thanks for the reply. The developer of the app I'm trying to use (Readerware) has sent me a copy of the comm.api and I've copied the library (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar into the proper places. When I try to run the application, I get this error... Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: /usr/lib/libSolarisSerialParallel.so: /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not little-endian (Possible cause: endianness mismatch) Caught java.lang.UnsatisfiedLinkError: com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I while loading driver com.sun.comm.SolarisDriver Is there a way around this error? Thanks again, Rick Knight From jlar310 at gmail.com Wed Aug 6 13:37:42 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 14:37:42 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899F8E3.5060400@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > The developer of the app I'm trying to use (Readerware) has sent me a > copy of the comm.api and I've copied the library > (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar > into the proper places. When I try to run the application, I get this > error... > > Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: > /usr/lib/libSolarisSerialParallel.so: > /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not > little-endian (Possible cause: endianness mismatch) > Caught java.lang.UnsatisfiedLinkError: > com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I > > while loading driver com.sun.comm.SolarisDriver > > Is there a way around this error? What host OS are you running? From your original post it looks like 32 bit Linux. The libSolarisSerialParallel.so file is for Sun Solaris and will vary depending on the underlying hardware architecture as well. Sorry for the double post Rick, but I failed to send this to the list the first time... -- Jeff From rick_knight at rlknight.com Wed Aug 6 13:44:29 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:44:29 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: <4899FF1D.9030504@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > > >> The developer of the app I'm trying to use (Readerware) has sent me a >> copy of the comm.api and I've copied the library >> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >> into the proper places. When I try to run the application, I get this >> error... >> >> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >> /usr/lib/libSolarisSerialParallel.so: >> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >> little-endian (Possible cause: endianness mismatch) >> Caught java.lang.UnsatisfiedLinkError: >> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >> >> while loading driver com.sun.comm.SolarisDriver >> >> Is there a way around this error? >> > > What host OS are you running? From your original post it looks like 32 > bit Linux. > > The libSolarisSerialParallel.so file is for Sun Solaris and will vary > depending on the underlying hardware architecture as well. > > I'm running Kubuntu Linux (debian based). It's 32 bit. Rick Knight From jlar310 at gmail.com Wed Aug 6 15:33:23 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 16:33:23 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > I don't think Sun did binary libraries for Linux in the 2.0 version. Can someone with more historical experience than I confirm that? I recently tried to port a Comm API application from Solaris sparc to Linux x86 and likewise could not get my hands on the binary libraries. I eventually just re-wrote the code to use the gnu namespace packages and rxtx 2.1. What I don't understand is why your application vendor does not provide everything you need to run their software. FYI: I have librxtxParallel.so and librxtxSerial.so installed at JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is /usr/java/default which is actually a softlink to /usr/java/jre1.6.0_05. -- Jeff From defiantlew at yahoo.com.au Wed Aug 6 16:29:33 2008 From: defiantlew at yahoo.com.au (Lew L) Date: Thu, 7 Aug 2008 08:29:33 +1000 Subject: [Rxtx] Sun's Comm API Documentation References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> Message-ID: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> As a matter of interest is the Sun Comm API documentation available somewhere? I have tried the Sun site but it seems to have been removed. Unless I have missed the documentation for RXTX? I javadocced the RXTX source but information (to me) is minimal. Somewhere I got the impression that the Sun Comm API docs is, or was, compatible with RXTX, what is the best docs to use in conjuntion with RXTX and where may the be available? Cheers Lew From rick_knight at rlknight.com Wed Aug 6 17:18:33 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:18:33 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A3149.4050306@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff I'm not sure if I posted this here or not, but when I try to build RXTX from source I get this install error... make all-am make[1]: Entering directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' make[1]: Nothing to be done for `all-am'. make[1]: Leaving directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 Can you tell me how to get past this error and get RXTX built and installed? Thanks, Rick From bboyes at systronix.com Wed Aug 6 17:40:12 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Wed, 06 Aug 2008 17:40:12 -0600 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: At 16:29 08/06/2008, Lew L wrote: >As a matter of interest is the Sun Comm API documentation available >somewhere? I have tried the Sun site but it seems to have been removed. It's in the file we have posted, link in prev email (sorry, in a huge hurry right now). Javadocs definitely there. >Unless I have missed the documentation for RXTX? I javadocced the RXTX >source but information (to me) is minimal. >Somewhere I got the impression that the Sun Comm API docs is, or was, >compatible with RXTX, what is the best docs to use in conjuntion with RXTX >and where may the be available? Yeah, this is one of my concerns/beefs. There is little documentation for RXTX and it isn't just the same as javaxcomm. I would be willing to help out writing docs for RXTX! Yes really... esp if we can fix the Bluetooth issues. best regards Bruce >Cheers >Lew > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx ------- WWW.SYSTRONIX.COM ---------- Real embedded Java and much more +1-801-534-1017 Salt Lake City, USA From rick_knight at rlknight.com Wed Aug 6 17:54:08 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:54:08 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A39A0.2090309@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff, I would like for my vendor to switch to rxtx 2.1. It would make things much easier for me. I'm not sure why he's still using the javax compatible code. He's a small operation. Re-writing the code to use gnu namespace sounds like a major overhaul. Was it? Thanks, Rick From tjarvi at qbang.org Wed Aug 6 21:35:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:35:12 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: >> >>> Jeff wrote: >>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>>> >>>> >>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things > much easier for me. I'm not sure why he's still using the javax > compatible code. He's a small operation. Re-writing the code to use gnu > namespace sounds like a major overhaul. Was it? > Hi Jeff, The changes are fairly mechanical. Imports need to change and any explicite use of the namespace needs to change such as catching an exception. The following script was made for maintaining rxtx 2.0 but can apply to other needs. It is in the contrib dir with rxtx source. #!/bin/sh # Don't use! :) # # Sat, 03 May 2003 16:45:08 Modifications from J?rg Weule # Create a ed-cmd for the change of one pattern # case $1 in gnu) X=g/javax_comm/s+javax_comm+gnu_io+g ;; javax) X=g/gnu_io/s+gnu_io+javax_comm+g ;; *) echo;echo;echo From the top rxtx directory run;echo;echo -e \\t./ChangePackage.sh gnu;echo -e \\t\\tor;echo -e \\t./ChangePackage.sh javax;echo;echo; exit 0 ;; esac # # ed will be used to keep the owner and mode of the files unchanged. # We have run the ed-script for the characters '.' '/' as well. # "tr _ $D" do the change. # find . -type f -a -print | grep -v $0 | (while read F ; do ( echo $X; echo $X| tr _ /; echo $X| tr _ .; echo w; echo q ) | ed $F 2>&1 >/dev/null done ) # # Now we do little changes at the Makefiles. Hope that all we need. # find . -name Makefile\* -a -print | (while read F ; do cat < References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: On Thu, 7 Aug 2008, Lew L wrote: > As a matter of interest is the Sun Comm API documentation available > somewhere? I have tried the Sun site but it seems to have been removed. > > Unless I have missed the documentation for RXTX? I javadocced the RXTX > source but information (to me) is minimal. > Somewhere I got the impression that the Sun Comm API docs is, or was, > compatible with RXTX, what is the best docs to use in conjuntion with RXTX > and where may the be available? > Hi Lew, The documentation on Sun's website is accurate. The changes that are problematic in 3.0 are on the backside which rxtx used to plug into. http://java.sun.com/products/javacomm/reference/api/index.html CommPortIdentifier may have some minor differences (judging by the authors notes). -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Aug 6 21:46:08 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:46:08 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > If javax.comm.properties is properly installed and you are using a 2.0 version of Sun's commapi with rxtx 2.0, you should not see the library attempt to load libSolarisSerialParallel.so. Sun CommAPI 3.0 will not work with any version of rxtx as it is hard coded to use the shared library. See the INSTALL file with rxtx-2.0 source for more help with the properties file. -- Trent Jarvi tjarvi at qbang.org From jlar310 at gmail.com Thu Aug 7 06:32:06 2008 From: jlar310 at gmail.com (Jeff) Date: Thu, 7 Aug 2008 07:32:06 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > Jeff wrote: >> >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >> wrote: >> >>> >>> Jeff wrote: >>> >>>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>> wrote: >>>> >>>> >>>> >>>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things much > easier for me. I'm not sure why he's still using the javax compatible code. > He's a small operation. Re-writing the code to use gnu namespace sounds like > a major overhaul. Was it? I found it quite easy. In fact, in order to accommodate the transition, I actually separated all of the code that deals directly with the Comm API or RXTX into a helper class. The helper class was then coded to use reflection to determine which library was available and then instantiate the necessary objects. No direct imports of either library are used. The main application just needs to get it's hands on the IO streams and need not deal directly with the libraries. Other programs may not be so simple... But this doesn't really help you unless your vendor forks over the source code... -- Jeff From rick_knight at rlknight.com Thu Aug 7 09:47:12 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Thu, 07 Aug 2008 08:47:12 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: <489B1900.10108@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >>> wrote: >>> >>> >>>> Jeff wrote: >>>> >>>> >>>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>>> copy of the comm.api and I've copied the library >>>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>>> into the proper places. When I try to run the application, I get this >>>>>> error... >>>>>> >>>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>>> /usr/lib/libSolarisSerialParallel.so: >>>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>>> little-endian (Possible cause: endianness mismatch) >>>>>> Caught java.lang.UnsatisfiedLinkError: >>>>>> >>>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>>> >>>>>> while loading driver com.sun.comm.SolarisDriver >>>>>> >>>>>> Is there a way around this error? >>>>>> >>>>>> >>>>>> >>>>> What host OS are you running? From your original post it looks like 32 >>>>> bit Linux. >>>>> >>>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>>> depending on the underlying hardware architecture as well. >>>>> >>>>> >>>>> >>>>> >>>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>>> >>>> >>>> >>> I don't think Sun did binary libraries for Linux in the 2.0 version. >>> Can someone with more historical experience than I confirm that? >>> >>> I recently tried to port a Comm API application from Solaris sparc to >>> Linux x86 and likewise could not get my hands on the binary libraries. >>> I eventually just re-wrote the code to use the gnu namespace packages >>> and rxtx 2.1. >>> >>> What I don't understand is why your application vendor does not >>> provide everything you need to run their software. >>> >>> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >>> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >>> /usr/java/default which is actually a softlink to >>> /usr/java/jre1.6.0_05. >>> >>> >>> >> Jeff, >> >> I would like for my vendor to switch to rxtx 2.1. It would make things much >> easier for me. I'm not sure why he's still using the javax compatible code. >> He's a small operation. Re-writing the code to use gnu namespace sounds like >> a major overhaul. Was it? >> > > I found it quite easy. In fact, in order to accommodate the > transition, I actually separated all of the code that deals directly > with the Comm API or RXTX into a helper class. The helper class was > then coded to use reflection to determine which library was available > and then instantiate the necessary objects. No direct imports of > either library are used. The main application just needs to get it's > hands on the IO streams and need not deal directly with the libraries. > Other programs may not be so simple... > > But this doesn't really help you unless your vendor forks over the > source code... > > Jeff, This may not help me directly, but I'm going to forward this thread to the vendor. I think he'll be open to making things work. Thanks again, Rick Knight From agusmunioz at gmail.com Thu Aug 7 16:39:51 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Thu, 7 Aug 2008 19:39:51 -0300 Subject: [Rxtx] How to send ack? Message-ID: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Hi, I'm still learning about serial communication and I have some doubts. I've got this question about how to do the following thing in rxtx. I have this hardware that connect to a PC using a serial port. These hardware receives data from a telephone line, proccess it, and then send it forward to the serial port. I've used a program named wincomm that shows what information is send it through the serial port and I have the nex behaviour: The hardware has a buffer where all data is stored, that cannot be sent it through the seria port. The program reads the first data send it by the hardware, and keep reading the same data always. There is a button in the application that says enable Ack, and when I click, then the hardware start to send all the stored information, and all the information is shown. I write a class, using rxtx that reads the serial port, and the same thing happens, it remains reading the same (first) data all the time. And I thing something like the enable Ack I'm missing. How can I do this enable Ack from my java code using rxtx? Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080807/e0a0f9a1/attachment-0008.html From ajmas at sympatico.ca Thu Aug 7 18:26:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 7 Aug 2008 20:26:41 -0400 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: <4BF42297-81E2-4BB8-A89F-1D43588379AE@sympatico.ca> On 6-Aug-08, at 19:40 , Bruce Boyes wrote: >> Unless I have missed the documentation for RXTX? I javadocced the >> RXTX >> source but information (to me) is minimal. >> Somewhere I got the impression that the Sun Comm API docs is, or was, >> compatible with RXTX, what is the best docs to use in conjuntion >> with RXTX >> and where may the be available? > > Yeah, this is one of my concerns/beefs. There is little documentation > for RXTX and it isn't just the same as javaxcomm. > > I would be willing to help out writing docs for RXTX! Yes really... > esp if we can fix the Bluetooth issues. If you want to contribute documentation then the best place to do that is the wiki. If there is anything missing or that could be improved on then please do so. If there are any points that you would like to see improved, for which you don't have the knowledge then ask on the mailing list for a volunteer. Andre From florianmanschwetus at gmx.de Fri Aug 8 03:04:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Fri, 08 Aug 2008 11:04:14 +0200 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Message-ID: <489C0C0E.2020401@gmx.de> Agustin Mu?oz schrieb: > Hi, I'm still learning about serial communication and I have some > doubts. I've got this question about how to do the following thing in rxtx. > I have this hardware that connect to a PC using a serial port. These > hardware receives data from a telephone line, proccess it, and then send > it forward to the serial port. I've used a program named wincomm that > shows what information is send it through the serial port and I have the > nex behaviour: > > The hardware has a buffer where all data is stored, that cannot be sent > it through the seria port. > The program reads the first data send it by the hardware, and keep > reading the same data always. > There is a button in the application that says enable Ack, and when I > click, then the hardware start to send all the stored information, and > all the information is shown. > > I write a class, using rxtx that reads the serial port, and the same > thing happens, it remains reading the same (first) data all the time. > And I thing something like the enable Ack I'm missing. > How can I do this enable Ack from my java code using rxtx? Afaik, a look at man ascii reveals: Okt Dez Hex Char 006 6 06 ACK So, i hope this will do the job: send(6); florian > > Thanks in advance > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/5b4965f8/attachment-0008.bin From agusmunioz at gmail.com Fri Aug 8 16:31:00 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 19:31:00 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <489C0C0E.2020401@gmx.de> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> Message-ID: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Hi Florian, thanks for the answer. By send(6) you mean to get the port OutputStream and write a 6? I try that but it didn't work. Any suggestion? Thanks On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < florianmanschwetus at gmx.de> wrote: > Agustin Mu?oz schrieb: > > Hi, I'm still learning about serial communication and I have some doubts. >> I've got this question about how to do the following thing in rxtx. >> I have this hardware that connect to a PC using a serial port. These >> hardware receives data from a telephone line, proccess it, and then send it >> forward to the serial port. I've used a program named wincomm that shows >> what information is send it through the serial port and I have the nex >> behaviour: >> >> The hardware has a buffer where all data is stored, that cannot be sent >> it through the seria port. >> The program reads the first data send it by the hardware, and keep reading >> the same data always. >> There is a button in the application that says enable Ack, and when I >> click, then the hardware start to send all the stored information, and all >> the information is shown. >> >> I write a class, using rxtx that reads the serial port, and the same thing >> happens, it remains reading the same (first) data all the time. And I thing >> something like the enable Ack I'm missing. >> How can I do this enable Ack from my java code using rxtx? >> > Afaik, a look at man ascii reveals: > Okt Dez Hex Char > 006 6 06 ACK > So, i hope this will do the job: > send(6); > > florian > >> >> Thanks in advance >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/7f3fba42/attachment-0007.html From agusmunioz at gmail.com Fri Aug 8 18:39:27 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 21:39:27 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Message-ID: <988288430808081739x7f9e7889id82591d5a9e2b4f6@mail.gmail.com> Ok, Florian, it works!! my problem was that I've been sending, through the OutputStream, the bytes of 6 as a string: out.write("6".getBytes()); but then I realized that you can write an int on an OuptuStream, so I tried that and It works: out.write(6); Thank you for the guidance!! On Fri, Aug 8, 2008 at 7:31 PM, Agustin Mu?oz wrote: > Hi Florian, thanks for the answer. By send(6) you mean to get the port > OutputStream and write a 6? > > I try that but it didn't work. > > Any suggestion? > > Thanks > > > On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < > florianmanschwetus at gmx.de> wrote: > >> Agustin Mu?oz schrieb: >> >> Hi, I'm still learning about serial communication and I have some doubts. >>> I've got this question about how to do the following thing in rxtx. >>> I have this hardware that connect to a PC using a serial port. These >>> hardware receives data from a telephone line, proccess it, and then send it >>> forward to the serial port. I've used a program named wincomm that shows >>> what information is send it through the serial port and I have the nex >>> behaviour: >>> >>> The hardware has a buffer where all data is stored, that cannot be sent >>> it through the seria port. >>> The program reads the first data send it by the hardware, and keep >>> reading the same data always. >>> There is a button in the application that says enable Ack, and when I >>> click, then the hardware start to send all the stored information, and all >>> the information is shown. >>> >>> I write a class, using rxtx that reads the serial port, and the same >>> thing happens, it remains reading the same (first) data all the time. And I >>> thing something like the enable Ack I'm missing. >>> How can I do this enable Ack from my java code using rxtx? >>> >> Afaik, a look at man ascii reveals: >> Okt Dez Hex Char >> 006 6 06 ACK >> So, i hope this will do the job: >> send(6); >> >> florian >> >>> >>> Thanks in advance >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/b918ab3d/attachment-0007.html From florianmanschwetus at gmx.de Sat Aug 9 00:45:43 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Sat, 09 Aug 2008 08:45:43 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4899667C.6010706@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> Message-ID: <489D3D17.9090209@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >> Florian Manschwetus wrote: >>> Ok, sounds fine for the receiving problem. >>> But why i have to wait after each byte when sending a command squence? >>> (the for loop in send command) >> >> Hi Florian, >> I'd imagine you probably don't! You could send all bytes in one go and >> RXTX would send them. The problem is most probably the other end: >> perhaps it has a really small buffer, some non-standard UART, or a >> crazy timing issue. If you attach a terminal to your output and send >> all the bytes of a command in one go they should appear no problem. >> >> Regards, >> Michael Erskine. >> > correct with a terminal on the other end it works, my idea was that this > basic baud has some influence. Could some one explain what it is for? > > Florian To make it more clear, my problem is that i can't use: outputStream.write(byte[]); => Beamer doesn't understand the sequence. (mostly no answer when he answers then *001) when i use this construct instead: for (int i = 0; i < command.length; i++) { this.outputStream.write(command[i]); try { Thread.sleep(25); } catch (InterruptedException e) { // TODO Auto-generated catch block e.printStackTrace(); } } it works nearly reliable. So what could it be? This Basic Baud is what exactly? Florian -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080809/692304ee/attachment-0007.bin From tjarvi at qbang.org Sat Aug 9 16:37:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Aug 2008 16:37:19 -0600 (MDT) Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489D3D17.9090209@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> <489D3D17.9090209@gmx.de> Message-ID: On Sat, 9 Aug 2008, Florian Manschwetus wrote: > Florian Manschwetus schrieb: >> Michael Erskine schrieb: >>> Florian Manschwetus wrote: >>>> Ok, sounds fine for the receiving problem. >>>> But why i have to wait after each byte when sending a command squence? >>>> (the for loop in send command) >>> >>> Hi Florian, >>> I'd imagine you probably don't! You could send all bytes in one go and >>> RXTX would send them. The problem is most probably the other end: perhaps >>> it has a really small buffer, some non-standard UART, or a crazy timing >>> issue. If you attach a terminal to your output and send all the bytes of a >>> command in one go they should appear no problem. >>> >>> Regards, >>> Michael Erskine. >>> >> correct with a terminal on the other end it works, my idea was that this >> basic baud has some influence. Could some one explain what it is for? >> >> Florian > To make it more clear, > my problem is that i can't use: > outputStream.write(byte[]); > => Beamer doesn't understand the sequence. (mostly no answer when he answers > then *001) > > when i use this construct instead: > > for (int i = 0; i < command.length; i++) { > this.outputStream.write(command[i]); > try { > Thread.sleep(25); > } catch (InterruptedException e) { > // TODO Auto-generated catch block > e.printStackTrace(); > } > } > > it works nearly reliable. > > So what could it be? This Basic Baud is what exactly? > I suspect you are using the 'moon protocol' and don't know it. RXTX enables this by default. The buffer on the other end is first in first out while reading. If the buffer is full, the bits are hand carried to the moon and burried. Then if the other side reads a couple bytes, two more bytes go into the buffer followed by more moon protocol. The resulting array of bytes the other side reads may appear to be scrambled until you go to the moon, get the bits and insert them in the right place. Flow control can prevent the default moon protocol and throttles the communiation by almost writing a byte at a time as need be. Hardware flow control is preferable but software flow control should also work. Read and write can appear to hang if the other side is not connected. This is why we don't enable them all the time. If you can't use flow control, you have to take care with the moon protocol and give the other side time to read. That is what your slower version of write is doing. -- Trent Jarvi tjarvi at qbang.org From rxtx at allenjb.me.uk Mon Aug 11 08:06:36 2008 From: rxtx at allenjb.me.uk (AllenJB) Date: Mon, 11 Aug 2008 15:06:36 +0100 Subject: [Rxtx] Disabling EV_RXFLAG Message-ID: <48A0476C.2090800@allenjb.me.uk> Hi all, I'm working with a device which does not use an EvtChar and need to disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an event mask of FD 01 00 00. The reference software I have uses FB 00 00 00. With the rxtx mask I get framing errors which I believe are caused when the EvtChar is received. Is there currently a way with rxtx (I've using rxtx from Java) to disable EV_RXFLAG? If not from Java, where would I start if I wanted to turn the EV_RXFLAG option off in the C code? I've had a grep of the rxtx source code, but I can't see where EV_RXFLAG is being set. Thanks in advance, AllenJB From tjarvi at qbang.org Mon Aug 11 14:17:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Aug 2008 14:17:27 -0600 (MDT) Subject: [Rxtx] Disabling EV_RXFLAG In-Reply-To: <48A0476C.2090800@allenjb.me.uk> References: <48A0476C.2090800@allenjb.me.uk> Message-ID: On Mon, 11 Aug 2008, AllenJB wrote: > Hi all, > > I'm working with a device which does not use an EvtChar and need to > disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an > event mask of FD 01 00 00. The reference software I have uses FB 00 00 > 00. With the rxtx mask I get framing errors which I believe are caused > when the EvtChar is received. > > Is there currently a way with rxtx (I've using rxtx from Java) to > disable EV_RXFLAG? > > If not from Java, where would I start if I wanted to turn the EV_RXFLAG > option off in the C code? I've had a grep of the rxtx source code, but I > can't see where EV_RXFLAG is being set. > > Thanks in advance, > > AllenJB Hi Allen, I'd look at termios.c::tcsetattr() and termios.c::FillDCB() -- Trent Jarvi tjarvi at qbang.org From superdadusa at gmail.com Tue Aug 12 13:57:32 2008 From: superdadusa at gmail.com (John Choi) Date: Tue, 12 Aug 2008 13:57:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. Message-ID: Hi all, Just let you all know I just start to learn Java. I have download the serial comm package and the source code from open source communities.. I was able to verify with the given message string via serial monitor. when the given message string sends to the serial port then the character return added to the end of string by default if I use "Hello World" however if I changed to something else other than "Hello, World" there is no character return add to the end of string. I thing the library download from rxtx.org has implemented for the special strings. I can do like "login\n" in the string message to make character return but I don't want to add this individual custom character for each command return in every static message string I send, Can any who have done this might help me? Basically, something like this,, Write and add function to the program write a command, Reads the respond from a serial device.. Function handles multiple messages, Write: "com open" Read: Welcome to my world" expected Write: "admin" Read: Password?, expected Write: "admin" Read: you are successfully login terminal, expected. And I need to add a separate function handler handles a character return add to the each command above. If anyone can help this I can do the reset? Thank you in advance, John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0003.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SerialIO.java Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0003.pl From Steffen.DETTMER at ingenico.com Wed Aug 13 02:16:38 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 13 Aug 2008 10:16:38 +0200 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: References: Message-ID: <20080813081638.GA25412@elberon.bln.de.ingenico.com> * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > I can do like "login\n" in the string message to make character > return but I don't want to add this individual custom character > for each command return in every static message string I send, and why not?! > Can any who have done this might help me? what's about with writing a small wrapper function adding the carriage return? However, this would be slow, because either you call write two times (very bad) or the string needs to be copied, \n appended and written (since you are using Java Performance probably isn't so critical). Personally I would write `"login\n"' and `username + "\n"' etc., because since it is part of the command it should be part of the command definition string. > Basically, something like this,, Write and add function to the program write > a command, Reads the respond from a serial device.. correctly reading a `line' is more difficult. If you cannot make assumptions about timeouts and/or you need to have low delay, you need to read byte wise. If you need to save CPU resources you might need to add some buffering layer that you can read byte-wise but that is reading blockwise with some small timeout (lets say for serial lines something around byte transmission time times three or so). > /* > * To change this template, choose Tools | Templates > * and open the template in the editor. > */ :) > package joliba; > > /** > * > * @author root > */ :) > // derived from SUN's examples in the javax.comm package > import java.io.*; > import java.util.*; > //import javax.comm.*; // for SUN's serial/parallel port libraries > import gnu.io.*; // for rxtxSerial library > > public class SerialIO implements Runnable, SerialPortEventListener { > static CommPortIdentifier portId; > static CommPortIdentifier saveportId; > static Enumeration portList; > InputStream inputStream; > SerialPort serialPort; > Thread readThread; You need a thread for your synchronous RPC-style protocol? > static String messageString = "Hello, world!"; > static OutputStream outputStream; > static boolean outputBufferEmptyFlag = false; > > public static void main(String[] args) { > boolean portFound = false; > String defaultPort; > > // determine the name of the serial port on several operating systems > String osname = System.getProperty("os.name","").toLowerCase(); > if ( osname.startsWith("windows") ) { > // windows > defaultPort = "COM1"; > } else if (osname.startsWith("linux")) { > // linux > defaultPort = "/dev/ttyS0"; > } else if ( osname.startsWith("mac") ) { > // mac > defaultPort = "????"; > } else { > System.out.println("Sorry, your operating system is not supported"); > return; > } Is such a construction recommended? Isn't there some abstraction (like COM1 working on any platform)? [...] > try { > // activate the OUTPUT_BUFFER_EMPTY notifier > serialPort.notifyOnOutputEmpty(true); > } catch (Exception e) { > System.out.println("Error setting event notification"); > System.out.println(e.toString()); > System.exit(-1); > } I doubt that -1 is defined, probably some 127 or so would be the result, maybe better simply `throw e'? > public void writetoport() { > System.out.println("Writing \""+messageString+"\" to "+serialPort.getName()); > try { > // write string to serial port > outputStream.write(messageString.getBytes()); > } catch (IOException e) {} > } maybe something like /** * Writes the given output string and an additional carriage * return to the current outputStream. */ public void writeStringToPort( /** The output string (without CR). */ String output ) throws IOException { String outputLine = output + "\n"; outputStream.write(outputLine.getBytes()); } ? > > public SerialIO() { > // initalize serial port > try { > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > } catch (PortInUseException e) {} if the port is in use, you continue? Wonder that this works in Java, I would assume serialPort beeing uninitialized which AFAIK is an error in Java. > try { > inputStream = serialPort.getInputStream(); > } catch (IOException e) {} > > try { > serialPort.addEventListener(this); > } catch (TooManyListenersException e) {} > > // activate the DATA_AVAILABLE notifier > serialPort.notifyOnDataAvailable(true); > > try { > // set port parameters > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > } catch (UnsupportedCommOperationException e) {} > > // start the read thread > readThread = new Thread(this); > readThread.start(); > > } I think in all those exception cases you can abort, because it is unlikely that ignoring those errors allow a successful continuation, so in this case maybe it would be better to add a throw clause to the method. > public void run() { > // first thing in the thread, we initialize the write operation > initwritetoport(); > try { > while (true) { > // write string to port, the serialEvent will read it > writetoport(); > Thread.sleep(1000); > } > } catch (InterruptedException e) {} > } Does this make sense? Your `SimpleReadApp' writes one and the same string each second? > public void serialEvent(SerialPortEvent event) { > switch (event.getEventType()) { > case SerialPortEvent.BI: > case SerialPortEvent.OE: > case SerialPortEvent.FE: > case SerialPortEvent.PE: > case SerialPortEvent.CD: > case SerialPortEvent.CTS: > case SerialPortEvent.DSR: > case SerialPortEvent.RI: > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > break; > case SerialPortEvent.DATA_AVAILABLE: > // we get here if data has been received > byte[] readBuffer = new byte[20]; > try { > // read data > while (inputStream.available() > 0) { > int numBytes = inputStream.read(readBuffer); > } > // print data > String result = new String(readBuffer); > System.out.println("Read: "+result); > } catch (IOException e) {} I doubt that this is correct. I would assume you will get a 20 bytes result always, if more bytes would be available they would be printed in a second line but if less bytes are read I'd assume that the buffer/result contains zero bytes from implicite readBuffer contents initialisation (zero is no string terminator in Java AFAIK). > break; > } > } > } oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From florianmanschwetus at gmx.de Wed Aug 13 06:09:31 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 13 Aug 2008 14:09:31 +0200 Subject: [Rxtx] someone has seen such errors? Message-ID: <48A2CEFB.90007@gmx.de> I mean my communication mostly works, but it is far from perfect could this be the reason? Florian Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/949b9947/attachment-0003.bin From superdadusa at gmail.com Wed Aug 13 08:40:32 2008 From: superdadusa at gmail.com (John Choi) Date: Wed, 13 Aug 2008 08:40:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: <20080813081638.GA25412@elberon.bln.de.ingenico.com> References: <20080813081638.GA25412@elberon.bln.de.ingenico.com> Message-ID: Thank you so much Steffen and I will try that suggestion. John On 8/13/08, Steffen DETTMER wrote: > > * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > > I can do like "login\n" in the string message to make character > > return but I don't want to add this individual custom character > > for each command return in every static message string I send, > > and why not?! > > > Can any who have done this might help me? > > what's about with writing a small wrapper function adding the > carriage return? > However, this would be slow, because either you call write two > times (very bad) or the string needs to be copied, \n appended > and written (since you are using Java Performance probably isn't > so critical). > > Personally I would write `"login\n"' and `username + "\n"' etc., > because since it is part of the command it should be part of the > command definition string. > > > Basically, something like this,, Write and add function to the program > write > > a command, Reads the respond from a serial device.. > > correctly reading a `line' is more difficult. If you cannot make > assumptions about timeouts and/or you need to have low delay, you > need to read byte wise. If you need to save CPU resources you > might need to add some buffering layer that you can read > byte-wise but that is reading blockwise with some small timeout > (lets say for serial lines something around byte transmission > time times three or so). > > > /* > > * To change this template, choose Tools | Templates > > * and open the template in the editor. > > */ > > :) > > > package joliba; > > > > /** > > * > > * @author root > > */ > > :) > > > // derived from SUN's examples in the javax.comm package > > import java.io.*; > > import java.util.*; > > //import javax.comm.*; // for SUN's serial/parallel port libraries > > import gnu.io.*; // for rxtxSerial library > > > > public class SerialIO implements Runnable, SerialPortEventListener { > > static CommPortIdentifier portId; > > static CommPortIdentifier saveportId; > > static Enumeration portList; > > InputStream inputStream; > > SerialPort serialPort; > > Thread readThread; > > You need a thread for your synchronous RPC-style protocol? > > > static String messageString = "Hello, world!"; > > static OutputStream outputStream; > > static boolean outputBufferEmptyFlag = false; > > > > public static void main(String[] args) { > > boolean portFound = false; > > String defaultPort; > > > > // determine the name of the serial port on several operating > systems > > String osname = System.getProperty("os.name","").toLowerCase(); > > if ( osname.startsWith("windows") ) { > > // windows > > defaultPort = "COM1"; > > } else if (osname.startsWith("linux")) { > > // linux > > defaultPort = "/dev/ttyS0"; > > } else if ( osname.startsWith("mac") ) { > > // mac > > defaultPort = "????"; > > } else { > > System.out.println("Sorry, your operating system is not > supported"); > > return; > > } > > Is such a construction recommended? Isn't there some abstraction > (like COM1 working on any platform)? > > [...] > > try { > > // activate the OUTPUT_BUFFER_EMPTY notifier > > serialPort.notifyOnOutputEmpty(true); > > } catch (Exception e) { > > System.out.println("Error setting event notification"); > > System.out.println(e.toString()); > > System.exit(-1); > > } > > I doubt that -1 is defined, probably some 127 or so would be the > result, maybe better simply `throw e'? > > > public void writetoport() { > > System.out.println("Writing \""+messageString+"\" to > "+serialPort.getName()); > > try { > > // write string to serial port > > outputStream.write(messageString.getBytes()); > > } catch (IOException e) {} > > } > > maybe something like > > /** > * Writes the given output string and an additional carriage > * return to the current outputStream. > */ > public void > writeStringToPort( > /** The output string (without CR). */ > String output > ) throws IOException > { > String outputLine = output + "\n"; > outputStream.write(outputLine.getBytes()); > } > > ? > > > > > public SerialIO() { > > // initalize serial port > > try { > > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > > } catch (PortInUseException e) {} > > if the port is in use, you continue? Wonder that this works in > Java, I would assume serialPort beeing uninitialized which AFAIK > is an error in Java. > > > try { > > inputStream = serialPort.getInputStream(); > > } catch (IOException e) {} > > > > try { > > serialPort.addEventListener(this); > > } catch (TooManyListenersException e) {} > > > > // activate the DATA_AVAILABLE notifier > > serialPort.notifyOnDataAvailable(true); > > > > try { > > // set port parameters > > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > } catch (UnsupportedCommOperationException e) {} > > > > // start the read thread > > readThread = new Thread(this); > > readThread.start(); > > > > } > > I think in all those exception cases you can abort, because it is > unlikely that ignoring those errors allow a successful > continuation, so in this case maybe it would be better to add a > throw clause to the method. > > > public void run() { > > // first thing in the thread, we initialize the write operation > > initwritetoport(); > > try { > > while (true) { > > // write string to port, the serialEvent will read it > > writetoport(); > > Thread.sleep(1000); > > } > > } catch (InterruptedException e) {} > > } > > Does this make sense? Your `SimpleReadApp' writes one and the > same string each second? > > > public void serialEvent(SerialPortEvent event) { > > switch (event.getEventType()) { > > case SerialPortEvent.BI: > > case SerialPortEvent.OE: > > case SerialPortEvent.FE: > > case SerialPortEvent.PE: > > case SerialPortEvent.CD: > > case SerialPortEvent.CTS: > > case SerialPortEvent.DSR: > > case SerialPortEvent.RI: > > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > > break; > > case SerialPortEvent.DATA_AVAILABLE: > > // we get here if data has been received > > byte[] readBuffer = new byte[20]; > > try { > > // read data > > while (inputStream.available() > 0) { > > int numBytes = inputStream.read(readBuffer); > > } > > // print data > > String result = new String(readBuffer); > > System.out.println("Read: "+result); > > } catch (IOException e) {} > > I doubt that this is correct. I would assume you will get a 20 > bytes result always, if more bytes would be available they would > be printed in a second line but if less bytes are read I'd assume > that the buffer/result contains zero bytes from implicite > readBuffer contents initialisation (zero is no string terminator > in Java AFAIK). > > > break; > > } > > } > > } > > oki, > > Steffen > > About Ingenico Throughout the world businesses rely on Ingenico for secure > and expedient electronic transaction acceptance. Ingenico products leverage > proven technology, established standards and unparalleled ergonomics to > provide optimal reliability, versatility and usability. This comprehensive > range of products is complemented by a global array of services and > partnerships, enabling businesses in a number of vertical sectors to accept > transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged > information. If you are not the addressee or authorized to receive this for > the addressee, you must not use, copy, disclose or take any action based on > this message or any information herein. If you have received this message in > error, please advise the sender immediately by reply e-mail and delete this > message. Thank you for your cooperation. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/73c4135c/attachment-0002.html From rick_knight at rlknight.com Mon Aug 4 13:25:10 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Mon, 04 Aug 2008 12:25:10 -0700 Subject: [Rxtx] Sun's Comm API? Message-ID: <48975796.4010600@rlknight.com> I have an application that requires the javax compatible version of RXTX and Sun's comm api. I've been able to download and extract the version of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api anywhere. Can someone tell me where I can find it? Or maybe send me a copy? Also, when I try to build RXTX, configure and make complete successfully but make install failes with this error libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 I've never come accross this error before. How can I get past it? Thanks, Rick From bboyes at systronix.com Mon Aug 4 19:10:01 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:10:01 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48975796.4010600@rlknight.com> References: <48975796.4010600@rlknight.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/cb9c6167/attachment-0012.html From bboyes at systronix.com Mon Aug 4 19:12:37 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:12:37 -0600 Subject: [Rxtx] Towards an RXTX release - CSR BT/USB chipset In-Reply-To: <488FB7E7.8000802@gmail.com> References: <460801A4097E3D4CA04CC64EE648584806C56CF0@ism-mail03.corp.ad.wrs.com> <13557-75390@sneakemail.com> <20980-23424@sneakemail.com> <488FB7E7.8000802@gmail.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/52236088/attachment-0012.html From tjarvi at qbang.org Mon Aug 4 19:42:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 19:42:21 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: On Mon, 4 Aug 2008, Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: > I have an application that requires the javax compatible > version of RXTX > and Sun's comm api. I've been able to download and extract > the version > of RXTX that I need (2.0-7pre2) but I can't find Sun's camm > api > anywhere. Can someone tell me where I can find it? Or maybe > send me a > > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm port > support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have just > a ZIP with only the .class JAR file - no source or docs), has a readme > with these comments: > > This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release.? The 2.0.3 release itself is > no longer distributed.? comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project.? The RxTx project (http://www.rxtx.org ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org) was opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support.? Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins.? Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > ? > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > I hope that is helpful! > It would be nice to work with Sun to resolve those longstanding issues. But it may not be practical unless the process goes as fast and painless as the grandfathering of commapi did. Another option may be the old kaffe extensions that moved to gnu classpathx. These don't have the native libraries but should provide the 2.0 interface and the javax.comm.properties mechansim for SPI. http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Mon Aug 4 20:23:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Mon, 04 Aug 2008 20:23:57 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4897B9BD.5070809@ergotech.com> Has there been any work/would it be possible, to layer a javacomm look-alike on top of the GNU code? The goal is not to move the javax code forward, but to emulate the "legacy" javax packages for people who still need this. Jim Trent Jarvi wrote: > On Mon, 4 Aug 2008, Bruce Boyes wrote: > >> At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible >> version of RXTX >> and Sun's comm api. I've been able to download and extract >> the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm >> api >> anywhere. Can someone tell me where I can find it? Or maybe >> send me a >> >> >> javaxcomm has had a sort of on-again off-again history. The windoze >> version has been languishing for years (literally) but there are newer >> versions for other OS's. >> >> We try to keep links on one of our help pages current: >> http://www.practicalembeddedjava.com/tools/javatools_list.html >> which gets you to here: >> http://java.sun.com/products/javacomm/ >> where it says in fact they no longer even support Windows and Mac: >> "Implementations of the API are currently available for Solaris SPARC, >> Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so >> someone could support it. But I guess that's part of the reason RXTX >> exists! >> >> So one of Sun's own products, SunSPOT, has to use RXTX to get comm port >> support. >> >> The version we use is 2.0 from 11/15/1998. I have posted it on our >> website, which is within the terms of the license agreement contained >> therein (as I understand it). >> >> The last version of javaxcomm for Windows, 2.0.3, (for which I have just >> a ZIP with only the .class JAR file - no source or docs), has a readme >> with these comments: >> >> This distribution contains the comm.jar file original part >> of the COMMAPI 2.0.3 release. The 2.0.3 release itself is >> no longer distributed. comm.jar, which contains the comm >> API java class files (eg. Sun's binary implementation of the >> interface classes), is being made available, unsupported, >> with no obligation to fix bugs, at the request of the RXTX >> project. The RxTx project (http://www.rxtx.org ), uses the >> comm.jar class files, but provides their own native library >> components to provide support for other platforms. >> >> The 2.0.3 comm.jar is being provided in this way because >> as of COMMAPI 3.x, the java binary implementation forked and >> became incompatible with the RxTx project's native code. >> Due to the lack of a clear business case, and to resource >> constraints, no additional resources are being >> provided to provide an alternative engineering solution >> at the time of writing. >> >> RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: >> >> Ultimately the COMMAPI would be better served if a Java >> Community Process JSR (http://www.jcp.org) was opened and >> the COMMAPI was rearchitected to provide a more pluggable >> framework to improve cross-platform support. Such an >> architecture would embody a better defined and better >> documented SPI interface, including a way for comm. ports >> to be revealed to the client application through the API >> via platform-aware plugins. Similarly, native code used >> to access comm port in general could be handled more >> flexibly using a plugin model, whereby on any platform, >> multiple native modules could be in use simultaneously. >> >> Since there are now various ways serial ports can be implemented >> and accessed, modular comm. port JNI native libraries would be >> of benefit insofar as removing the burden of over-generalization >> from any single native component, or inversely, by relieving the >> implicit constraint that comm. drivers be accessed only via a >> monolithic mechanism, such as the UNIX vnode interface. >> >> paul.klissner at sun.com >> 6/10/06 >> >> I hope that is helpful! >> > > It would be nice to work with Sun to resolve those longstanding issues. > But it may not be practical unless the process goes as fast and painless > as the grandfathering of commapi did. > > Another option may be the old kaffe extensions that moved to gnu > classpathx. These don't have the native libraries but should provide > the 2.0 interface and the javax.comm.properties mechansim for SPI. > > http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Mon Aug 4 21:09:15 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 21:09:15 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? Message-ID: Hi Jim, I will not step into the javax.comm namespace without Sun's explicite permission. I fully understand the pain point you are trying to address. In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm Linux) - which remains an integral part of rxtx. At the time it was a win for Sun and rxtx. The Sun commapi license is/was fairly clear that rxtx should not step into that namespace. It made sense as Sun was active in that space and rxtx may go into another namespace - it was an experiment in working with Sun. This may sound silly looking at something that happened almost 10 years ago. In a community of respect which Sun helped create, there is no question about what to do. I hope eventually Sun will step up and do a right thing too. I agree that this is hurting the API more than helping it. There are also questions about how to replace the API in the long term which includes HID support which isn't going well so far. Others that can't even look at Sun's javax.comm today and can look at Kaffe's contribution to classpathx can easily work around such restrictions. On Mon, 4 Aug 2008, Jim Redman wrote: > Has there been any work/would it be possible, to layer a javacomm > look-alike on top of the GNU code? > > The goal is not to move the javax code forward, but to emulate the > "legacy" javax packages for people who still need this. > > Jim > > Trent Jarvi wrote: >> >> It would be nice to work with Sun to resolve those longstanding issues. >> But it may not be practical unless the process goes as fast and painless >> as the grandfathering of commapi did. >> >> Another option may be the old kaffe extensions that moved to gnu >> classpathx. These don't have the native libraries but should provide >> the 2.0 interface and the javax.comm.properties mechansim for SPI. >> >> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From florianmanschwetus at gmx.de Tue Aug 5 05:04:46 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 13:04:46 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: References: <48971C1F.9020806@gmx.de> Message-ID: <489833CE.1040801@gmx.de> Just look at sendCommand in this method I have to place a Thread.sleep(20) after each byte send to get working. Even the event based receive doesn't work fine but this could be may stupidness. The specifikation document (it is on the last pages of the manual) for the beamer could be found on: http://www.optoma.co.uk/support.aspx Florian Manschwetus Trent Jarvi schrieb: > > Hi Florian > > Sorry for the top post in advance. I worry you may not see my answer > under all your code :) > > I have not received this email before. This is 500k of code which I > don't have time to read. I can spend about 5 min on each hobby email > and still get to work in the morning. I have a couple suggestions for > how to get an answer. > > First, cut out your comments and extra code so you can demonstrate the > question (I might even glance and see what is wrong then). Don't go for > a working final product. Isolate the problem using a simple program and > then ask with that as an example. If I did what you just did, I'd have > to post 3/4 of a million lines of code :) > > Second, join the rxtx mail-list and ask there. This will give you 100x > more eyes. I'll also read and try to follow. > > -- > taj > > > > On Mon, 4 Aug 2008, Florian Manschwetus wrote: > >> It could be that my university account is blocked by filters so >> resending from here. >> >> >> Topic is to control Optoma HD80 beamer using rs232 serial chat. >> This code is able to detect power state and switch the beamer on / off. >> connected is the beamer using a digitus usb 2.0 serial adapter with an >> FT232 USB-Serial adapter the systems architecture is amd64. >> >> Please take a look in the sendCommand routine i have to place theire >> those Thread.sleep to get it working. >> Now the question is this correct or is there a better way to get this >> working correctly? >> >> In the javadoc coming with the install i found this: >> setBaudBase >> >> public boolean setBaudBase(int BaudBase) >> throws UnsupportedCommOperationException, >> java.io.IOException >> >> Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 >> before using. >> >> could this explain the error? >> I attached my java source and the protocol description for the beamer >> (available on vendor website). >> >> thx, >> Florian Manschwetus >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: TestRS232.java Type: text/x-java Size: 9143 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0024.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0025.bin From michael.erskine at ketech.com Tue Aug 5 05:53:49 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Tue, 5 Aug 2008 12:53:49 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489833CE.1040801@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> > Just look at sendCommand in this method I have to place a > Thread.sleep(20) after each byte send to get working. Even the event > based receive doesn't work fine but this could be may stupidness. Hi Florian, Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. Regards, Michael Erskine. From florianmanschwetus at gmx.de Tue Aug 5 07:28:15 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:28:15 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> Message-ID: <4898556F.8000208@gmx.de> Michael Erskine schrieb: >> Just look at sendCommand in this method I have to place a >> Thread.sleep(20) after each byte send to get working. Even the event >> based receive doesn't work fine but this could be may stupidness. > > Hi Florian, > > Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. > > Regards, > Michael Erskine. > Ok, sounds fine for the receiving problem. But why i have to wait after each byte when sending a command squence? (the for loop in send command) Florian > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/284f350c/attachment-0011.bin From florianmanschwetus at gmx.de Tue Aug 5 07:44:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:44:14 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <4898592E.2020908@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >>> Just look at sendCommand in this method I have to place a >>> Thread.sleep(20) after each byte send to get working. Even the event >>> based receive doesn't work fine but this could be may stupidness. >> >> Hi Florian, >> >> Yes, naturally you'll have to wait for a response from the other end. >> Why not wait for notification from the event thread perhaps using a >> BlockingDeque rather than your LinkedList. Generally I >> try to decouple all input and output streams: in your case your >> application is operating synchronously like the "expect" program >> (http://expect.nist.gov/) so waits (or timeouts) will need to be >> factored in. >> >> Regards, >> Michael Erskine. >> > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) > > Florian Furthermore there is this basic baud with this confusing javadoc entry: public boolean setBaudBase(int BaudBase) throws UnsupportedCommOperationException, java.io.IOException Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 before using. maybe this could explain something Florian >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/006c7425/attachment-0011.bin From jredman at ergotech.com Tue Aug 5 09:13:36 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 05 Aug 2008 09:13:36 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: Message-ID: <48986E20.3060104@ergotech.com> Trent, So two issues: 1) Technically I'm still not sure how easy/practical a layer would be. The problems are always classes like listeners, and wrapping returns of gnu.io classes. I really see it as a "delegate" type of concept. Any thoughts or ideas of the practicality of this approach? The idea is not to modify RXTX. 2) Javax. The javax namespace does seem to be in widespread use outside of Sun (the same is true for the java namespace). The classpath extensions, or some other location, should be interested in a JavaComm implementation even if it does have dependencies on RXTX. Would you have any philosophical objection to an approach like that? Of course, I suspect it might be better if someone with that authority at Sun would admit that the javax namespace is already in the wild and that there is no problem with it being used within RXTX. Jim Trent Jarvi wrote: > Hi Jim, > > I will not step into the javax.comm namespace without Sun's explicite > permission. I fully understand the pain point you are trying to address. > > In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm > Linux) - which remains an integral part of rxtx. At the time it was a win for > Sun and rxtx. > > The Sun commapi license is/was fairly clear that rxtx should not step into that > namespace. It made sense as Sun was active in that space and rxtx may go into > another namespace - it was an experiment in working with Sun. > > This may sound silly looking at something that happened almost 10 years ago. > In a community of respect which Sun helped create, there is no question about > what to do. I hope eventually Sun will step up and do a right thing too. > > I agree that this is hurting the API more than helping it. There are also > questions about how to replace the API in the long term which includes HID > support which isn't going well so far. > > Others that can't even look at Sun's javax.comm today and can look at Kaffe's > contribution to classpathx can easily work around such restrictions. > > On Mon, 4 Aug 2008, Jim Redman wrote: > >> Has there been any work/would it be possible, to layer a javacomm >> look-alike on top of the GNU code? >> >> The goal is not to move the javax code forward, but to emulate the >> "legacy" javax packages for people who still need this. >> >> Jim >> >> Trent Jarvi wrote: >>> It would be nice to work with Sun to resolve those longstanding issues. >>> But it may not be practical unless the process goes as fast and painless >>> as the grandfathering of commapi did. >>> >>> Another option may be the old kaffe extensions that moved to gnu >>> classpathx. These don't have the native libraries but should provide >>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>> >>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From sandeep at genevasoftech.com Tue Aug 5 11:18:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Tue, 05 Aug 2008 22:48:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <48988B6C.5080409@genevasoftech.com> Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. *-- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/ad20f1cb/attachment-0011.html From Martin.Oberhuber at windriver.com Tue Aug 5 13:30:17 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Tue, 5 Aug 2008 21:30:17 +0200 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Sandeep, shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on Sol7 but I've successfully run it on Sol9 and Sol10. Or is your request really about a native 64bit variant? I'm afraid that then you're out of luck since I think that quite a bit of RXTX is not yet ready for 64 bit. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Sandeep Kumar K Sent: Tuesday, August 05, 2008 7:19 PM To: rxtx at qbang.org Subject: [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so for Solaris 9 Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. -- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/81b7f988/attachment-0011.html From tjarvi at qbang.org Tue Aug 5 22:38:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 22:38:34 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 5 Aug 2008, Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built > on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid that > then > you're out of luck since I think that quite a bit of RXTX is not yet > ready > for 64 bit. > While rxtx-2.1-7 probably has problems, The CVS code should be OK for 64 bit Solaris. If it isn't, let me know and I'll find which patch is missing. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Aug 5 23:13:00 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 23:13:00 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48986E20.3060104@ergotech.com> References: <48986E20.3060104@ergotech.com> Message-ID: On Tue, 5 Aug 2008, Jim Redman wrote: > Trent, > > So two issues: > > 1) Technically I'm still not sure how easy/practical a layer would be. The > problems are always classes like listeners, and wrapping returns of gnu.io > classes. I really see it as a "delegate" type of concept. Any thoughts or > ideas of the practicality of this approach? The idea is not to modify RXTX. I have not put too much thought into this. I assume you want what rxtx 2.0 provided to tie into javax.comm implementations. More classes could be added to rxtx 2.1-7 for SPI support. Maintaining rxtx-2.0 could also be handed to someone if they like. > > 2) Javax. The javax namespace does seem to be in widespread use outside of > Sun (the same is true for the java namespace). The classpath extensions, or > some other location, should be interested in a JavaComm implementation even > if it does have dependencies on RXTX. Would you have any philosophical > objection to an approach like that? > No problems. Classpathx would be a possible place to do it. I'd suggest thinking twice about what this involves in practical terms. You would be wanting to revive the 2.0 API while Sun is at 3.0 and grandfathering the JSR. This undermines the main reason (established api) for using the javax.comm namespace and does not leave such a project in a good position. The only win I see here is maintaining support for applications that can't migrate namespaces. Not that that isn't important. At some point it is going to be less work to just edit the bytecode :) Such a javax.comm effort would also be signing up new projects that decided to use the work up for concerns they probably will not understand or expect. That probably isn't a good path to facilitate for new projects at this time. We will put a good faith effort to work well with others but keep in mind the project has limited bandwidth for such efforts. > Of course, I suspect it might be better if someone with that authority at Sun > would admit that the javax namespace is already in the wild and that there is > no problem with it being used within RXTX. > > Jim > > Trent Jarvi wrote: >> Hi Jim, >> >> I will not step into the javax.comm namespace without Sun's explicite >> permission. I fully understand the pain point you are trying to address. >> >> In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java >> Comm Linux) - which remains an integral part of rxtx. At the time it was a >> win for Sun and rxtx. >> >> The Sun commapi license is/was fairly clear that rxtx should not step into >> that namespace. It made sense as Sun was active in that space and rxtx may >> go into another namespace - it was an experiment in working with Sun. >> >> This may sound silly looking at something that happened almost 10 years >> ago. In a community of respect which Sun helped create, there is no >> question about what to do. I hope eventually Sun will step up and do a >> right thing too. >> >> I agree that this is hurting the API more than helping it. There are also >> questions about how to replace the API in the long term which includes HID >> support which isn't going well so far. >> >> Others that can't even look at Sun's javax.comm today and can look at >> Kaffe's contribution to classpathx can easily work around such >> restrictions. >> >> On Mon, 4 Aug 2008, Jim Redman wrote: >> >>> Has there been any work/would it be possible, to layer a javacomm >>> look-alike on top of the GNU code? >>> >>> The goal is not to move the javax code forward, but to emulate the >>> "legacy" javax packages for people who still need this. >>> >>> Jim >>> >>> Trent Jarvi wrote: >>>> It would be nice to work with Sun to resolve those longstanding issues. >>>> But it may not be practical unless the process goes as fast and painless >>>> as the grandfathering of commapi did. >>>> >>>> Another option may be the old kaffe extensions that moved to gnu >>>> classpathx. These don't have the native libraries but should provide >>>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>>> >>>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From sandeep at genevasoftech.com Wed Aug 6 00:03:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Wed, 06 Aug 2008 11:33:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: <48993EB8.30107@genevasoftech.com> Thank you Mr. Martin for your suggestion. The native file which is given in rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am getting the following error . Any suggestions to solve this issue. I am using Solaris SPARC 64 bit machine. ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) thrown while loading gnu.io.RXTXCommDriver Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(Unknown Source) at java.lang.ClassLoader.loadLibrary(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) at com.ReadFromModem.main(ReadFromModem.java:84) * * *Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid > that then > you're out of luck since I think that quite a bit of RXTX is not yet ready > for 64 bit. > > Cheers, > -- > *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > ------------------------------------------------------------------------ > *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On > Behalf Of *Sandeep Kumar K > *Sent:* Tuesday, August 05, 2008 7:19 PM > *To:* rxtx at qbang.org > *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so > for Solaris 9 > > Hi, > > Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 > bit machine. The librxtxSerial.so given in website is for Solaris 8. > > *-- > > Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/1e920343/attachment-0011.html From tjarvi at qbang.org Wed Aug 6 00:21:42 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 00:21:42 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <48993EB8.30107@genevasoftech.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> <48993EB8.30107@genevasoftech.com> Message-ID: Hi Sandeep You may be out of luck unless you can compile the 2.1 src in CVS (requires gnu make and gcc). But you could try the ToyBox(R)(TM) which is a collection of WiLdLy untested cross compiled 2.1-7 binaries covering everything from the ibm z series to embeded arm/ppc. To give an idea how poorly these are tested, I don't even know if z series machines have a serial port. ftp://www.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Solaris They should at least match the binary types. Actually, I think if you use the rxtx jar from CVS with that file, it should 'work' as the fix for 64 bits was in java not the native code. You could just cd rxtx*/src; javac *.java then jar -cf RXTXcomm.jar `find -name \*.class` to create the hybrid which will complain about version information a bit. On Wed, 6 Aug 2008, Sandeep Kumar K wrote: > Thank you Mr. Martin for your suggestion. The native file which is given in > rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am > getting the following error . > Any suggestions to solve this issue. > I am using Solaris SPARC 64 bit machine. > > ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar > java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 > (Possible cause: architecture word > width mismatch) thrown while loading gnu.io.RXTXCommDriver > Exception in thread "main" java.lang.UnsatisfiedLinkError: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF > class: ELFCLASS64 (Possible cause: > architecture word width mismatch) > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(Unknown Source) > at java.lang.ClassLoader.loadLibrary(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > at com.ReadFromModem.main(ReadFromModem.java:84) > > * > * > > *Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > > > Oberhuber, Martin wrote: >> Sandeep, >> shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse >> variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on >> Sol7 but I've successfully run it on Sol9 and Sol10. >> Or is your request really about a native 64bit variant? I'm afraid that >> then >> you're out of luck since I think that quite a bit of RXTX is not yet ready >> for 64 bit. >> Cheers, >> -- >> *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> ------------------------------------------------------------------------ >> *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On >> Behalf Of *Sandeep Kumar K >> *Sent:* Tuesday, August 05, 2008 7:19 PM >> *To:* rxtx at qbang.org >> *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so >> for Solaris 9 >> >> Hi, >> >> Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 >> bit machine. The librxtxSerial.so given in website is for Solaris 8. >> >> *-- >> Thanks & Regards >> >> Sandeep Kumar K >> Sr. Software Engineer >> Geneva Software Technologies >> Whitefield, Bangalore >> Mob : 9880193454* >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> From michael.erskine at ketech.com Wed Aug 6 01:39:28 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 6 Aug 2008 08:39:28 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Florian Manschwetus wrote: > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) Hi Florian, I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. Regards, Michael Erskine. From florianmanschwetus at gmx.de Wed Aug 6 02:53:16 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 06 Aug 2008 10:53:16 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Message-ID: <4899667C.6010706@gmx.de> Michael Erskine schrieb: > Florian Manschwetus wrote: >> Ok, sounds fine for the receiving problem. >> But why i have to wait after each byte when sending a command squence? >> (the for loop in send command) > > Hi Florian, > I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. > > Regards, > Michael Erskine. > correct with a terminal on the other end it works, my idea was that this basic baud has some influence. Could some one explain what it is for? Florian > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/c2b4fa84/attachment-0011.bin From rick_knight at rlknight.com Wed Aug 6 13:01:07 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:01:07 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F4F3.3020707@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > I have an application (Readerware) that uses RXTX with Javax to access the serial port. This used to work fine under previous Linux' and Java, but something has changed, I assume with Java itself , that is causing the application to fail with a link error. The application is not able to find librxtxSerialParallel.so. RXTX supplies librxtxSerial.so and librxtxParallel.so, but not librxtxSerialParallel.so. Where can I get librxtxSerialParallel.so, or do I need it? Is something else causing the lib to not be found? Thanks, Rick Knight From rick_knight at rlknight.com Wed Aug 6 13:17:55 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:17:55 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F8E3.5060400@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Thanks for the reply. The developer of the app I'm trying to use (Readerware) has sent me a copy of the comm.api and I've copied the library (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar into the proper places. When I try to run the application, I get this error... Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: /usr/lib/libSolarisSerialParallel.so: /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not little-endian (Possible cause: endianness mismatch) Caught java.lang.UnsatisfiedLinkError: com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I while loading driver com.sun.comm.SolarisDriver Is there a way around this error? Thanks again, Rick Knight From jlar310 at gmail.com Wed Aug 6 13:37:42 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 14:37:42 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899F8E3.5060400@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > The developer of the app I'm trying to use (Readerware) has sent me a > copy of the comm.api and I've copied the library > (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar > into the proper places. When I try to run the application, I get this > error... > > Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: > /usr/lib/libSolarisSerialParallel.so: > /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not > little-endian (Possible cause: endianness mismatch) > Caught java.lang.UnsatisfiedLinkError: > com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I > > while loading driver com.sun.comm.SolarisDriver > > Is there a way around this error? What host OS are you running? From your original post it looks like 32 bit Linux. The libSolarisSerialParallel.so file is for Sun Solaris and will vary depending on the underlying hardware architecture as well. Sorry for the double post Rick, but I failed to send this to the list the first time... -- Jeff From rick_knight at rlknight.com Wed Aug 6 13:44:29 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:44:29 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: <4899FF1D.9030504@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > > >> The developer of the app I'm trying to use (Readerware) has sent me a >> copy of the comm.api and I've copied the library >> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >> into the proper places. When I try to run the application, I get this >> error... >> >> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >> /usr/lib/libSolarisSerialParallel.so: >> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >> little-endian (Possible cause: endianness mismatch) >> Caught java.lang.UnsatisfiedLinkError: >> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >> >> while loading driver com.sun.comm.SolarisDriver >> >> Is there a way around this error? >> > > What host OS are you running? From your original post it looks like 32 > bit Linux. > > The libSolarisSerialParallel.so file is for Sun Solaris and will vary > depending on the underlying hardware architecture as well. > > I'm running Kubuntu Linux (debian based). It's 32 bit. Rick Knight From jlar310 at gmail.com Wed Aug 6 15:33:23 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 16:33:23 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > I don't think Sun did binary libraries for Linux in the 2.0 version. Can someone with more historical experience than I confirm that? I recently tried to port a Comm API application from Solaris sparc to Linux x86 and likewise could not get my hands on the binary libraries. I eventually just re-wrote the code to use the gnu namespace packages and rxtx 2.1. What I don't understand is why your application vendor does not provide everything you need to run their software. FYI: I have librxtxParallel.so and librxtxSerial.so installed at JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is /usr/java/default which is actually a softlink to /usr/java/jre1.6.0_05. -- Jeff From defiantlew at yahoo.com.au Wed Aug 6 16:29:33 2008 From: defiantlew at yahoo.com.au (Lew L) Date: Thu, 7 Aug 2008 08:29:33 +1000 Subject: [Rxtx] Sun's Comm API Documentation References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> Message-ID: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> As a matter of interest is the Sun Comm API documentation available somewhere? I have tried the Sun site but it seems to have been removed. Unless I have missed the documentation for RXTX? I javadocced the RXTX source but information (to me) is minimal. Somewhere I got the impression that the Sun Comm API docs is, or was, compatible with RXTX, what is the best docs to use in conjuntion with RXTX and where may the be available? Cheers Lew From rick_knight at rlknight.com Wed Aug 6 17:18:33 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:18:33 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A3149.4050306@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff I'm not sure if I posted this here or not, but when I try to build RXTX from source I get this install error... make all-am make[1]: Entering directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' make[1]: Nothing to be done for `all-am'. make[1]: Leaving directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 Can you tell me how to get past this error and get RXTX built and installed? Thanks, Rick From bboyes at systronix.com Wed Aug 6 17:40:12 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Wed, 06 Aug 2008 17:40:12 -0600 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: At 16:29 08/06/2008, Lew L wrote: >As a matter of interest is the Sun Comm API documentation available >somewhere? I have tried the Sun site but it seems to have been removed. It's in the file we have posted, link in prev email (sorry, in a huge hurry right now). Javadocs definitely there. >Unless I have missed the documentation for RXTX? I javadocced the RXTX >source but information (to me) is minimal. >Somewhere I got the impression that the Sun Comm API docs is, or was, >compatible with RXTX, what is the best docs to use in conjuntion with RXTX >and where may the be available? Yeah, this is one of my concerns/beefs. There is little documentation for RXTX and it isn't just the same as javaxcomm. I would be willing to help out writing docs for RXTX! Yes really... esp if we can fix the Bluetooth issues. best regards Bruce >Cheers >Lew > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx ------- WWW.SYSTRONIX.COM ---------- Real embedded Java and much more +1-801-534-1017 Salt Lake City, USA From rick_knight at rlknight.com Wed Aug 6 17:54:08 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:54:08 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A39A0.2090309@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff, I would like for my vendor to switch to rxtx 2.1. It would make things much easier for me. I'm not sure why he's still using the javax compatible code. He's a small operation. Re-writing the code to use gnu namespace sounds like a major overhaul. Was it? Thanks, Rick From tjarvi at qbang.org Wed Aug 6 21:35:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:35:12 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: >> >>> Jeff wrote: >>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>>> >>>> >>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things > much easier for me. I'm not sure why he's still using the javax > compatible code. He's a small operation. Re-writing the code to use gnu > namespace sounds like a major overhaul. Was it? > Hi Jeff, The changes are fairly mechanical. Imports need to change and any explicite use of the namespace needs to change such as catching an exception. The following script was made for maintaining rxtx 2.0 but can apply to other needs. It is in the contrib dir with rxtx source. #!/bin/sh # Don't use! :) # # Sat, 03 May 2003 16:45:08 Modifications from J?rg Weule # Create a ed-cmd for the change of one pattern # case $1 in gnu) X=g/javax_comm/s+javax_comm+gnu_io+g ;; javax) X=g/gnu_io/s+gnu_io+javax_comm+g ;; *) echo;echo;echo From the top rxtx directory run;echo;echo -e \\t./ChangePackage.sh gnu;echo -e \\t\\tor;echo -e \\t./ChangePackage.sh javax;echo;echo; exit 0 ;; esac # # ed will be used to keep the owner and mode of the files unchanged. # We have run the ed-script for the characters '.' '/' as well. # "tr _ $D" do the change. # find . -type f -a -print | grep -v $0 | (while read F ; do ( echo $X; echo $X| tr _ /; echo $X| tr _ .; echo w; echo q ) | ed $F 2>&1 >/dev/null done ) # # Now we do little changes at the Makefiles. Hope that all we need. # find . -name Makefile\* -a -print | (while read F ; do cat < References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: On Thu, 7 Aug 2008, Lew L wrote: > As a matter of interest is the Sun Comm API documentation available > somewhere? I have tried the Sun site but it seems to have been removed. > > Unless I have missed the documentation for RXTX? I javadocced the RXTX > source but information (to me) is minimal. > Somewhere I got the impression that the Sun Comm API docs is, or was, > compatible with RXTX, what is the best docs to use in conjuntion with RXTX > and where may the be available? > Hi Lew, The documentation on Sun's website is accurate. The changes that are problematic in 3.0 are on the backside which rxtx used to plug into. http://java.sun.com/products/javacomm/reference/api/index.html CommPortIdentifier may have some minor differences (judging by the authors notes). -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Aug 6 21:46:08 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:46:08 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > If javax.comm.properties is properly installed and you are using a 2.0 version of Sun's commapi with rxtx 2.0, you should not see the library attempt to load libSolarisSerialParallel.so. Sun CommAPI 3.0 will not work with any version of rxtx as it is hard coded to use the shared library. See the INSTALL file with rxtx-2.0 source for more help with the properties file. -- Trent Jarvi tjarvi at qbang.org From jlar310 at gmail.com Thu Aug 7 06:32:06 2008 From: jlar310 at gmail.com (Jeff) Date: Thu, 7 Aug 2008 07:32:06 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > Jeff wrote: >> >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >> wrote: >> >>> >>> Jeff wrote: >>> >>>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>> wrote: >>>> >>>> >>>> >>>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things much > easier for me. I'm not sure why he's still using the javax compatible code. > He's a small operation. Re-writing the code to use gnu namespace sounds like > a major overhaul. Was it? I found it quite easy. In fact, in order to accommodate the transition, I actually separated all of the code that deals directly with the Comm API or RXTX into a helper class. The helper class was then coded to use reflection to determine which library was available and then instantiate the necessary objects. No direct imports of either library are used. The main application just needs to get it's hands on the IO streams and need not deal directly with the libraries. Other programs may not be so simple... But this doesn't really help you unless your vendor forks over the source code... -- Jeff From rick_knight at rlknight.com Thu Aug 7 09:47:12 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Thu, 07 Aug 2008 08:47:12 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: <489B1900.10108@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >>> wrote: >>> >>> >>>> Jeff wrote: >>>> >>>> >>>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>>> copy of the comm.api and I've copied the library >>>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>>> into the proper places. When I try to run the application, I get this >>>>>> error... >>>>>> >>>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>>> /usr/lib/libSolarisSerialParallel.so: >>>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>>> little-endian (Possible cause: endianness mismatch) >>>>>> Caught java.lang.UnsatisfiedLinkError: >>>>>> >>>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>>> >>>>>> while loading driver com.sun.comm.SolarisDriver >>>>>> >>>>>> Is there a way around this error? >>>>>> >>>>>> >>>>>> >>>>> What host OS are you running? From your original post it looks like 32 >>>>> bit Linux. >>>>> >>>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>>> depending on the underlying hardware architecture as well. >>>>> >>>>> >>>>> >>>>> >>>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>>> >>>> >>>> >>> I don't think Sun did binary libraries for Linux in the 2.0 version. >>> Can someone with more historical experience than I confirm that? >>> >>> I recently tried to port a Comm API application from Solaris sparc to >>> Linux x86 and likewise could not get my hands on the binary libraries. >>> I eventually just re-wrote the code to use the gnu namespace packages >>> and rxtx 2.1. >>> >>> What I don't understand is why your application vendor does not >>> provide everything you need to run their software. >>> >>> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >>> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >>> /usr/java/default which is actually a softlink to >>> /usr/java/jre1.6.0_05. >>> >>> >>> >> Jeff, >> >> I would like for my vendor to switch to rxtx 2.1. It would make things much >> easier for me. I'm not sure why he's still using the javax compatible code. >> He's a small operation. Re-writing the code to use gnu namespace sounds like >> a major overhaul. Was it? >> > > I found it quite easy. In fact, in order to accommodate the > transition, I actually separated all of the code that deals directly > with the Comm API or RXTX into a helper class. The helper class was > then coded to use reflection to determine which library was available > and then instantiate the necessary objects. No direct imports of > either library are used. The main application just needs to get it's > hands on the IO streams and need not deal directly with the libraries. > Other programs may not be so simple... > > But this doesn't really help you unless your vendor forks over the > source code... > > Jeff, This may not help me directly, but I'm going to forward this thread to the vendor. I think he'll be open to making things work. Thanks again, Rick Knight From agusmunioz at gmail.com Thu Aug 7 16:39:51 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Thu, 7 Aug 2008 19:39:51 -0300 Subject: [Rxtx] How to send ack? Message-ID: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Hi, I'm still learning about serial communication and I have some doubts. I've got this question about how to do the following thing in rxtx. I have this hardware that connect to a PC using a serial port. These hardware receives data from a telephone line, proccess it, and then send it forward to the serial port. I've used a program named wincomm that shows what information is send it through the serial port and I have the nex behaviour: The hardware has a buffer where all data is stored, that cannot be sent it through the seria port. The program reads the first data send it by the hardware, and keep reading the same data always. There is a button in the application that says enable Ack, and when I click, then the hardware start to send all the stored information, and all the information is shown. I write a class, using rxtx that reads the serial port, and the same thing happens, it remains reading the same (first) data all the time. And I thing something like the enable Ack I'm missing. How can I do this enable Ack from my java code using rxtx? Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080807/e0a0f9a1/attachment-0009.html From ajmas at sympatico.ca Thu Aug 7 18:26:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 7 Aug 2008 20:26:41 -0400 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: <4BF42297-81E2-4BB8-A89F-1D43588379AE@sympatico.ca> On 6-Aug-08, at 19:40 , Bruce Boyes wrote: >> Unless I have missed the documentation for RXTX? I javadocced the >> RXTX >> source but information (to me) is minimal. >> Somewhere I got the impression that the Sun Comm API docs is, or was, >> compatible with RXTX, what is the best docs to use in conjuntion >> with RXTX >> and where may the be available? > > Yeah, this is one of my concerns/beefs. There is little documentation > for RXTX and it isn't just the same as javaxcomm. > > I would be willing to help out writing docs for RXTX! Yes really... > esp if we can fix the Bluetooth issues. If you want to contribute documentation then the best place to do that is the wiki. If there is anything missing or that could be improved on then please do so. If there are any points that you would like to see improved, for which you don't have the knowledge then ask on the mailing list for a volunteer. Andre From florianmanschwetus at gmx.de Fri Aug 8 03:04:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Fri, 08 Aug 2008 11:04:14 +0200 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Message-ID: <489C0C0E.2020401@gmx.de> Agustin Mu?oz schrieb: > Hi, I'm still learning about serial communication and I have some > doubts. I've got this question about how to do the following thing in rxtx. > I have this hardware that connect to a PC using a serial port. These > hardware receives data from a telephone line, proccess it, and then send > it forward to the serial port. I've used a program named wincomm that > shows what information is send it through the serial port and I have the > nex behaviour: > > The hardware has a buffer where all data is stored, that cannot be sent > it through the seria port. > The program reads the first data send it by the hardware, and keep > reading the same data always. > There is a button in the application that says enable Ack, and when I > click, then the hardware start to send all the stored information, and > all the information is shown. > > I write a class, using rxtx that reads the serial port, and the same > thing happens, it remains reading the same (first) data all the time. > And I thing something like the enable Ack I'm missing. > How can I do this enable Ack from my java code using rxtx? Afaik, a look at man ascii reveals: Okt Dez Hex Char 006 6 06 ACK So, i hope this will do the job: send(6); florian > > Thanks in advance > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/5b4965f8/attachment-0009.bin From agusmunioz at gmail.com Fri Aug 8 16:31:00 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 19:31:00 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <489C0C0E.2020401@gmx.de> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> Message-ID: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Hi Florian, thanks for the answer. By send(6) you mean to get the port OutputStream and write a 6? I try that but it didn't work. Any suggestion? Thanks On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < florianmanschwetus at gmx.de> wrote: > Agustin Mu?oz schrieb: > > Hi, I'm still learning about serial communication and I have some doubts. >> I've got this question about how to do the following thing in rxtx. >> I have this hardware that connect to a PC using a serial port. These >> hardware receives data from a telephone line, proccess it, and then send it >> forward to the serial port. I've used a program named wincomm that shows >> what information is send it through the serial port and I have the nex >> behaviour: >> >> The hardware has a buffer where all data is stored, that cannot be sent >> it through the seria port. >> The program reads the first data send it by the hardware, and keep reading >> the same data always. >> There is a button in the application that says enable Ack, and when I >> click, then the hardware start to send all the stored information, and all >> the information is shown. >> >> I write a class, using rxtx that reads the serial port, and the same thing >> happens, it remains reading the same (first) data all the time. And I thing >> something like the enable Ack I'm missing. >> How can I do this enable Ack from my java code using rxtx? >> > Afaik, a look at man ascii reveals: > Okt Dez Hex Char > 006 6 06 ACK > So, i hope this will do the job: > send(6); > > florian > >> >> Thanks in advance >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/7f3fba42/attachment-0008.html From agusmunioz at gmail.com Fri Aug 8 18:39:27 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 21:39:27 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Message-ID: <988288430808081739x7f9e7889id82591d5a9e2b4f6@mail.gmail.com> Ok, Florian, it works!! my problem was that I've been sending, through the OutputStream, the bytes of 6 as a string: out.write("6".getBytes()); but then I realized that you can write an int on an OuptuStream, so I tried that and It works: out.write(6); Thank you for the guidance!! On Fri, Aug 8, 2008 at 7:31 PM, Agustin Mu?oz wrote: > Hi Florian, thanks for the answer. By send(6) you mean to get the port > OutputStream and write a 6? > > I try that but it didn't work. > > Any suggestion? > > Thanks > > > On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < > florianmanschwetus at gmx.de> wrote: > >> Agustin Mu?oz schrieb: >> >> Hi, I'm still learning about serial communication and I have some doubts. >>> I've got this question about how to do the following thing in rxtx. >>> I have this hardware that connect to a PC using a serial port. These >>> hardware receives data from a telephone line, proccess it, and then send it >>> forward to the serial port. I've used a program named wincomm that shows >>> what information is send it through the serial port and I have the nex >>> behaviour: >>> >>> The hardware has a buffer where all data is stored, that cannot be sent >>> it through the seria port. >>> The program reads the first data send it by the hardware, and keep >>> reading the same data always. >>> There is a button in the application that says enable Ack, and when I >>> click, then the hardware start to send all the stored information, and all >>> the information is shown. >>> >>> I write a class, using rxtx that reads the serial port, and the same >>> thing happens, it remains reading the same (first) data all the time. And I >>> thing something like the enable Ack I'm missing. >>> How can I do this enable Ack from my java code using rxtx? >>> >> Afaik, a look at man ascii reveals: >> Okt Dez Hex Char >> 006 6 06 ACK >> So, i hope this will do the job: >> send(6); >> >> florian >> >>> >>> Thanks in advance >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/b918ab3d/attachment-0008.html From florianmanschwetus at gmx.de Sat Aug 9 00:45:43 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Sat, 09 Aug 2008 08:45:43 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4899667C.6010706@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> Message-ID: <489D3D17.9090209@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >> Florian Manschwetus wrote: >>> Ok, sounds fine for the receiving problem. >>> But why i have to wait after each byte when sending a command squence? >>> (the for loop in send command) >> >> Hi Florian, >> I'd imagine you probably don't! You could send all bytes in one go and >> RXTX would send them. The problem is most probably the other end: >> perhaps it has a really small buffer, some non-standard UART, or a >> crazy timing issue. If you attach a terminal to your output and send >> all the bytes of a command in one go they should appear no problem. >> >> Regards, >> Michael Erskine. >> > correct with a terminal on the other end it works, my idea was that this > basic baud has some influence. Could some one explain what it is for? > > Florian To make it more clear, my problem is that i can't use: outputStream.write(byte[]); => Beamer doesn't understand the sequence. (mostly no answer when he answers then *001) when i use this construct instead: for (int i = 0; i < command.length; i++) { this.outputStream.write(command[i]); try { Thread.sleep(25); } catch (InterruptedException e) { // TODO Auto-generated catch block e.printStackTrace(); } } it works nearly reliable. So what could it be? This Basic Baud is what exactly? Florian -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080809/692304ee/attachment-0008.bin From tjarvi at qbang.org Sat Aug 9 16:37:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Aug 2008 16:37:19 -0600 (MDT) Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489D3D17.9090209@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> <489D3D17.9090209@gmx.de> Message-ID: On Sat, 9 Aug 2008, Florian Manschwetus wrote: > Florian Manschwetus schrieb: >> Michael Erskine schrieb: >>> Florian Manschwetus wrote: >>>> Ok, sounds fine for the receiving problem. >>>> But why i have to wait after each byte when sending a command squence? >>>> (the for loop in send command) >>> >>> Hi Florian, >>> I'd imagine you probably don't! You could send all bytes in one go and >>> RXTX would send them. The problem is most probably the other end: perhaps >>> it has a really small buffer, some non-standard UART, or a crazy timing >>> issue. If you attach a terminal to your output and send all the bytes of a >>> command in one go they should appear no problem. >>> >>> Regards, >>> Michael Erskine. >>> >> correct with a terminal on the other end it works, my idea was that this >> basic baud has some influence. Could some one explain what it is for? >> >> Florian > To make it more clear, > my problem is that i can't use: > outputStream.write(byte[]); > => Beamer doesn't understand the sequence. (mostly no answer when he answers > then *001) > > when i use this construct instead: > > for (int i = 0; i < command.length; i++) { > this.outputStream.write(command[i]); > try { > Thread.sleep(25); > } catch (InterruptedException e) { > // TODO Auto-generated catch block > e.printStackTrace(); > } > } > > it works nearly reliable. > > So what could it be? This Basic Baud is what exactly? > I suspect you are using the 'moon protocol' and don't know it. RXTX enables this by default. The buffer on the other end is first in first out while reading. If the buffer is full, the bits are hand carried to the moon and burried. Then if the other side reads a couple bytes, two more bytes go into the buffer followed by more moon protocol. The resulting array of bytes the other side reads may appear to be scrambled until you go to the moon, get the bits and insert them in the right place. Flow control can prevent the default moon protocol and throttles the communiation by almost writing a byte at a time as need be. Hardware flow control is preferable but software flow control should also work. Read and write can appear to hang if the other side is not connected. This is why we don't enable them all the time. If you can't use flow control, you have to take care with the moon protocol and give the other side time to read. That is what your slower version of write is doing. -- Trent Jarvi tjarvi at qbang.org From rxtx at allenjb.me.uk Mon Aug 11 08:06:36 2008 From: rxtx at allenjb.me.uk (AllenJB) Date: Mon, 11 Aug 2008 15:06:36 +0100 Subject: [Rxtx] Disabling EV_RXFLAG Message-ID: <48A0476C.2090800@allenjb.me.uk> Hi all, I'm working with a device which does not use an EvtChar and need to disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an event mask of FD 01 00 00. The reference software I have uses FB 00 00 00. With the rxtx mask I get framing errors which I believe are caused when the EvtChar is received. Is there currently a way with rxtx (I've using rxtx from Java) to disable EV_RXFLAG? If not from Java, where would I start if I wanted to turn the EV_RXFLAG option off in the C code? I've had a grep of the rxtx source code, but I can't see where EV_RXFLAG is being set. Thanks in advance, AllenJB From tjarvi at qbang.org Mon Aug 11 14:17:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Aug 2008 14:17:27 -0600 (MDT) Subject: [Rxtx] Disabling EV_RXFLAG In-Reply-To: <48A0476C.2090800@allenjb.me.uk> References: <48A0476C.2090800@allenjb.me.uk> Message-ID: On Mon, 11 Aug 2008, AllenJB wrote: > Hi all, > > I'm working with a device which does not use an EvtChar and need to > disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an > event mask of FD 01 00 00. The reference software I have uses FB 00 00 > 00. With the rxtx mask I get framing errors which I believe are caused > when the EvtChar is received. > > Is there currently a way with rxtx (I've using rxtx from Java) to > disable EV_RXFLAG? > > If not from Java, where would I start if I wanted to turn the EV_RXFLAG > option off in the C code? I've had a grep of the rxtx source code, but I > can't see where EV_RXFLAG is being set. > > Thanks in advance, > > AllenJB Hi Allen, I'd look at termios.c::tcsetattr() and termios.c::FillDCB() -- Trent Jarvi tjarvi at qbang.org From superdadusa at gmail.com Tue Aug 12 13:57:32 2008 From: superdadusa at gmail.com (John Choi) Date: Tue, 12 Aug 2008 13:57:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. Message-ID: Hi all, Just let you all know I just start to learn Java. I have download the serial comm package and the source code from open source communities.. I was able to verify with the given message string via serial monitor. when the given message string sends to the serial port then the character return added to the end of string by default if I use "Hello World" however if I changed to something else other than "Hello, World" there is no character return add to the end of string. I thing the library download from rxtx.org has implemented for the special strings. I can do like "login\n" in the string message to make character return but I don't want to add this individual custom character for each command return in every static message string I send, Can any who have done this might help me? Basically, something like this,, Write and add function to the program write a command, Reads the respond from a serial device.. Function handles multiple messages, Write: "com open" Read: Welcome to my world" expected Write: "admin" Read: Password?, expected Write: "admin" Read: you are successfully login terminal, expected. And I need to add a separate function handler handles a character return add to the each command above. If anyone can help this I can do the reset? Thank you in advance, John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0004.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SerialIO.java Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0004.pl From Steffen.DETTMER at ingenico.com Wed Aug 13 02:16:38 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 13 Aug 2008 10:16:38 +0200 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: References: Message-ID: <20080813081638.GA25412@elberon.bln.de.ingenico.com> * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > I can do like "login\n" in the string message to make character > return but I don't want to add this individual custom character > for each command return in every static message string I send, and why not?! > Can any who have done this might help me? what's about with writing a small wrapper function adding the carriage return? However, this would be slow, because either you call write two times (very bad) or the string needs to be copied, \n appended and written (since you are using Java Performance probably isn't so critical). Personally I would write `"login\n"' and `username + "\n"' etc., because since it is part of the command it should be part of the command definition string. > Basically, something like this,, Write and add function to the program write > a command, Reads the respond from a serial device.. correctly reading a `line' is more difficult. If you cannot make assumptions about timeouts and/or you need to have low delay, you need to read byte wise. If you need to save CPU resources you might need to add some buffering layer that you can read byte-wise but that is reading blockwise with some small timeout (lets say for serial lines something around byte transmission time times three or so). > /* > * To change this template, choose Tools | Templates > * and open the template in the editor. > */ :) > package joliba; > > /** > * > * @author root > */ :) > // derived from SUN's examples in the javax.comm package > import java.io.*; > import java.util.*; > //import javax.comm.*; // for SUN's serial/parallel port libraries > import gnu.io.*; // for rxtxSerial library > > public class SerialIO implements Runnable, SerialPortEventListener { > static CommPortIdentifier portId; > static CommPortIdentifier saveportId; > static Enumeration portList; > InputStream inputStream; > SerialPort serialPort; > Thread readThread; You need a thread for your synchronous RPC-style protocol? > static String messageString = "Hello, world!"; > static OutputStream outputStream; > static boolean outputBufferEmptyFlag = false; > > public static void main(String[] args) { > boolean portFound = false; > String defaultPort; > > // determine the name of the serial port on several operating systems > String osname = System.getProperty("os.name","").toLowerCase(); > if ( osname.startsWith("windows") ) { > // windows > defaultPort = "COM1"; > } else if (osname.startsWith("linux")) { > // linux > defaultPort = "/dev/ttyS0"; > } else if ( osname.startsWith("mac") ) { > // mac > defaultPort = "????"; > } else { > System.out.println("Sorry, your operating system is not supported"); > return; > } Is such a construction recommended? Isn't there some abstraction (like COM1 working on any platform)? [...] > try { > // activate the OUTPUT_BUFFER_EMPTY notifier > serialPort.notifyOnOutputEmpty(true); > } catch (Exception e) { > System.out.println("Error setting event notification"); > System.out.println(e.toString()); > System.exit(-1); > } I doubt that -1 is defined, probably some 127 or so would be the result, maybe better simply `throw e'? > public void writetoport() { > System.out.println("Writing \""+messageString+"\" to "+serialPort.getName()); > try { > // write string to serial port > outputStream.write(messageString.getBytes()); > } catch (IOException e) {} > } maybe something like /** * Writes the given output string and an additional carriage * return to the current outputStream. */ public void writeStringToPort( /** The output string (without CR). */ String output ) throws IOException { String outputLine = output + "\n"; outputStream.write(outputLine.getBytes()); } ? > > public SerialIO() { > // initalize serial port > try { > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > } catch (PortInUseException e) {} if the port is in use, you continue? Wonder that this works in Java, I would assume serialPort beeing uninitialized which AFAIK is an error in Java. > try { > inputStream = serialPort.getInputStream(); > } catch (IOException e) {} > > try { > serialPort.addEventListener(this); > } catch (TooManyListenersException e) {} > > // activate the DATA_AVAILABLE notifier > serialPort.notifyOnDataAvailable(true); > > try { > // set port parameters > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > } catch (UnsupportedCommOperationException e) {} > > // start the read thread > readThread = new Thread(this); > readThread.start(); > > } I think in all those exception cases you can abort, because it is unlikely that ignoring those errors allow a successful continuation, so in this case maybe it would be better to add a throw clause to the method. > public void run() { > // first thing in the thread, we initialize the write operation > initwritetoport(); > try { > while (true) { > // write string to port, the serialEvent will read it > writetoport(); > Thread.sleep(1000); > } > } catch (InterruptedException e) {} > } Does this make sense? Your `SimpleReadApp' writes one and the same string each second? > public void serialEvent(SerialPortEvent event) { > switch (event.getEventType()) { > case SerialPortEvent.BI: > case SerialPortEvent.OE: > case SerialPortEvent.FE: > case SerialPortEvent.PE: > case SerialPortEvent.CD: > case SerialPortEvent.CTS: > case SerialPortEvent.DSR: > case SerialPortEvent.RI: > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > break; > case SerialPortEvent.DATA_AVAILABLE: > // we get here if data has been received > byte[] readBuffer = new byte[20]; > try { > // read data > while (inputStream.available() > 0) { > int numBytes = inputStream.read(readBuffer); > } > // print data > String result = new String(readBuffer); > System.out.println("Read: "+result); > } catch (IOException e) {} I doubt that this is correct. I would assume you will get a 20 bytes result always, if more bytes would be available they would be printed in a second line but if less bytes are read I'd assume that the buffer/result contains zero bytes from implicite readBuffer contents initialisation (zero is no string terminator in Java AFAIK). > break; > } > } > } oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From florianmanschwetus at gmx.de Wed Aug 13 06:09:31 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 13 Aug 2008 14:09:31 +0200 Subject: [Rxtx] someone has seen such errors? Message-ID: <48A2CEFB.90007@gmx.de> I mean my communication mostly works, but it is far from perfect could this be the reason? Florian Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/949b9947/attachment-0004.bin From superdadusa at gmail.com Wed Aug 13 08:40:32 2008 From: superdadusa at gmail.com (John Choi) Date: Wed, 13 Aug 2008 08:40:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: <20080813081638.GA25412@elberon.bln.de.ingenico.com> References: <20080813081638.GA25412@elberon.bln.de.ingenico.com> Message-ID: Thank you so much Steffen and I will try that suggestion. John On 8/13/08, Steffen DETTMER wrote: > > * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > > I can do like "login\n" in the string message to make character > > return but I don't want to add this individual custom character > > for each command return in every static message string I send, > > and why not?! > > > Can any who have done this might help me? > > what's about with writing a small wrapper function adding the > carriage return? > However, this would be slow, because either you call write two > times (very bad) or the string needs to be copied, \n appended > and written (since you are using Java Performance probably isn't > so critical). > > Personally I would write `"login\n"' and `username + "\n"' etc., > because since it is part of the command it should be part of the > command definition string. > > > Basically, something like this,, Write and add function to the program > write > > a command, Reads the respond from a serial device.. > > correctly reading a `line' is more difficult. If you cannot make > assumptions about timeouts and/or you need to have low delay, you > need to read byte wise. If you need to save CPU resources you > might need to add some buffering layer that you can read > byte-wise but that is reading blockwise with some small timeout > (lets say for serial lines something around byte transmission > time times three or so). > > > /* > > * To change this template, choose Tools | Templates > > * and open the template in the editor. > > */ > > :) > > > package joliba; > > > > /** > > * > > * @author root > > */ > > :) > > > // derived from SUN's examples in the javax.comm package > > import java.io.*; > > import java.util.*; > > //import javax.comm.*; // for SUN's serial/parallel port libraries > > import gnu.io.*; // for rxtxSerial library > > > > public class SerialIO implements Runnable, SerialPortEventListener { > > static CommPortIdentifier portId; > > static CommPortIdentifier saveportId; > > static Enumeration portList; > > InputStream inputStream; > > SerialPort serialPort; > > Thread readThread; > > You need a thread for your synchronous RPC-style protocol? > > > static String messageString = "Hello, world!"; > > static OutputStream outputStream; > > static boolean outputBufferEmptyFlag = false; > > > > public static void main(String[] args) { > > boolean portFound = false; > > String defaultPort; > > > > // determine the name of the serial port on several operating > systems > > String osname = System.getProperty("os.name","").toLowerCase(); > > if ( osname.startsWith("windows") ) { > > // windows > > defaultPort = "COM1"; > > } else if (osname.startsWith("linux")) { > > // linux > > defaultPort = "/dev/ttyS0"; > > } else if ( osname.startsWith("mac") ) { > > // mac > > defaultPort = "????"; > > } else { > > System.out.println("Sorry, your operating system is not > supported"); > > return; > > } > > Is such a construction recommended? Isn't there some abstraction > (like COM1 working on any platform)? > > [...] > > try { > > // activate the OUTPUT_BUFFER_EMPTY notifier > > serialPort.notifyOnOutputEmpty(true); > > } catch (Exception e) { > > System.out.println("Error setting event notification"); > > System.out.println(e.toString()); > > System.exit(-1); > > } > > I doubt that -1 is defined, probably some 127 or so would be the > result, maybe better simply `throw e'? > > > public void writetoport() { > > System.out.println("Writing \""+messageString+"\" to > "+serialPort.getName()); > > try { > > // write string to serial port > > outputStream.write(messageString.getBytes()); > > } catch (IOException e) {} > > } > > maybe something like > > /** > * Writes the given output string and an additional carriage > * return to the current outputStream. > */ > public void > writeStringToPort( > /** The output string (without CR). */ > String output > ) throws IOException > { > String outputLine = output + "\n"; > outputStream.write(outputLine.getBytes()); > } > > ? > > > > > public SerialIO() { > > // initalize serial port > > try { > > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > > } catch (PortInUseException e) {} > > if the port is in use, you continue? Wonder that this works in > Java, I would assume serialPort beeing uninitialized which AFAIK > is an error in Java. > > > try { > > inputStream = serialPort.getInputStream(); > > } catch (IOException e) {} > > > > try { > > serialPort.addEventListener(this); > > } catch (TooManyListenersException e) {} > > > > // activate the DATA_AVAILABLE notifier > > serialPort.notifyOnDataAvailable(true); > > > > try { > > // set port parameters > > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > } catch (UnsupportedCommOperationException e) {} > > > > // start the read thread > > readThread = new Thread(this); > > readThread.start(); > > > > } > > I think in all those exception cases you can abort, because it is > unlikely that ignoring those errors allow a successful > continuation, so in this case maybe it would be better to add a > throw clause to the method. > > > public void run() { > > // first thing in the thread, we initialize the write operation > > initwritetoport(); > > try { > > while (true) { > > // write string to port, the serialEvent will read it > > writetoport(); > > Thread.sleep(1000); > > } > > } catch (InterruptedException e) {} > > } > > Does this make sense? Your `SimpleReadApp' writes one and the > same string each second? > > > public void serialEvent(SerialPortEvent event) { > > switch (event.getEventType()) { > > case SerialPortEvent.BI: > > case SerialPortEvent.OE: > > case SerialPortEvent.FE: > > case SerialPortEvent.PE: > > case SerialPortEvent.CD: > > case SerialPortEvent.CTS: > > case SerialPortEvent.DSR: > > case SerialPortEvent.RI: > > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > > break; > > case SerialPortEvent.DATA_AVAILABLE: > > // we get here if data has been received > > byte[] readBuffer = new byte[20]; > > try { > > // read data > > while (inputStream.available() > 0) { > > int numBytes = inputStream.read(readBuffer); > > } > > // print data > > String result = new String(readBuffer); > > System.out.println("Read: "+result); > > } catch (IOException e) {} > > I doubt that this is correct. I would assume you will get a 20 > bytes result always, if more bytes would be available they would > be printed in a second line but if less bytes are read I'd assume > that the buffer/result contains zero bytes from implicite > readBuffer contents initialisation (zero is no string terminator > in Java AFAIK). > > > break; > > } > > } > > } > > oki, > > Steffen > > About Ingenico Throughout the world businesses rely on Ingenico for secure > and expedient electronic transaction acceptance. Ingenico products leverage > proven technology, established standards and unparalleled ergonomics to > provide optimal reliability, versatility and usability. This comprehensive > range of products is complemented by a global array of services and > partnerships, enabling businesses in a number of vertical sectors to accept > transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged > information. If you are not the addressee or authorized to receive this for > the addressee, you must not use, copy, disclose or take any action based on > this message or any information herein. If you have received this message in > error, please advise the sender immediately by reply e-mail and delete this > message. Thank you for your cooperation. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/73c4135c/attachment-0003.html From rick_knight at rlknight.com Mon Aug 4 13:25:10 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Mon, 04 Aug 2008 12:25:10 -0700 Subject: [Rxtx] Sun's Comm API? Message-ID: <48975796.4010600@rlknight.com> I have an application that requires the javax compatible version of RXTX and Sun's comm api. I've been able to download and extract the version of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api anywhere. Can someone tell me where I can find it? Or maybe send me a copy? Also, when I try to build RXTX, configure and make complete successfully but make install failes with this error libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 I've never come accross this error before. How can I get past it? Thanks, Rick From bboyes at systronix.com Mon Aug 4 19:10:01 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:10:01 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48975796.4010600@rlknight.com> References: <48975796.4010600@rlknight.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/cb9c6167/attachment-0013.html From bboyes at systronix.com Mon Aug 4 19:12:37 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:12:37 -0600 Subject: [Rxtx] Towards an RXTX release - CSR BT/USB chipset In-Reply-To: <488FB7E7.8000802@gmail.com> References: <460801A4097E3D4CA04CC64EE648584806C56CF0@ism-mail03.corp.ad.wrs.com> <13557-75390@sneakemail.com> <20980-23424@sneakemail.com> <488FB7E7.8000802@gmail.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/52236088/attachment-0013.html From tjarvi at qbang.org Mon Aug 4 19:42:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 19:42:21 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: On Mon, 4 Aug 2008, Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: > I have an application that requires the javax compatible > version of RXTX > and Sun's comm api. I've been able to download and extract > the version > of RXTX that I need (2.0-7pre2) but I can't find Sun's camm > api > anywhere. Can someone tell me where I can find it? Or maybe > send me a > > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm port > support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have just > a ZIP with only the .class JAR file - no source or docs), has a readme > with these comments: > > This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release.? The 2.0.3 release itself is > no longer distributed.? comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project.? The RxTx project (http://www.rxtx.org ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org) was opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support.? Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins.? Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > ? > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > I hope that is helpful! > It would be nice to work with Sun to resolve those longstanding issues. But it may not be practical unless the process goes as fast and painless as the grandfathering of commapi did. Another option may be the old kaffe extensions that moved to gnu classpathx. These don't have the native libraries but should provide the 2.0 interface and the javax.comm.properties mechansim for SPI. http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Mon Aug 4 20:23:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Mon, 04 Aug 2008 20:23:57 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4897B9BD.5070809@ergotech.com> Has there been any work/would it be possible, to layer a javacomm look-alike on top of the GNU code? The goal is not to move the javax code forward, but to emulate the "legacy" javax packages for people who still need this. Jim Trent Jarvi wrote: > On Mon, 4 Aug 2008, Bruce Boyes wrote: > >> At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible >> version of RXTX >> and Sun's comm api. I've been able to download and extract >> the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm >> api >> anywhere. Can someone tell me where I can find it? Or maybe >> send me a >> >> >> javaxcomm has had a sort of on-again off-again history. The windoze >> version has been languishing for years (literally) but there are newer >> versions for other OS's. >> >> We try to keep links on one of our help pages current: >> http://www.practicalembeddedjava.com/tools/javatools_list.html >> which gets you to here: >> http://java.sun.com/products/javacomm/ >> where it says in fact they no longer even support Windows and Mac: >> "Implementations of the API are currently available for Solaris SPARC, >> Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so >> someone could support it. But I guess that's part of the reason RXTX >> exists! >> >> So one of Sun's own products, SunSPOT, has to use RXTX to get comm port >> support. >> >> The version we use is 2.0 from 11/15/1998. I have posted it on our >> website, which is within the terms of the license agreement contained >> therein (as I understand it). >> >> The last version of javaxcomm for Windows, 2.0.3, (for which I have just >> a ZIP with only the .class JAR file - no source or docs), has a readme >> with these comments: >> >> This distribution contains the comm.jar file original part >> of the COMMAPI 2.0.3 release. The 2.0.3 release itself is >> no longer distributed. comm.jar, which contains the comm >> API java class files (eg. Sun's binary implementation of the >> interface classes), is being made available, unsupported, >> with no obligation to fix bugs, at the request of the RXTX >> project. The RxTx project (http://www.rxtx.org ), uses the >> comm.jar class files, but provides their own native library >> components to provide support for other platforms. >> >> The 2.0.3 comm.jar is being provided in this way because >> as of COMMAPI 3.x, the java binary implementation forked and >> became incompatible with the RxTx project's native code. >> Due to the lack of a clear business case, and to resource >> constraints, no additional resources are being >> provided to provide an alternative engineering solution >> at the time of writing. >> >> RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: >> >> Ultimately the COMMAPI would be better served if a Java >> Community Process JSR (http://www.jcp.org) was opened and >> the COMMAPI was rearchitected to provide a more pluggable >> framework to improve cross-platform support. Such an >> architecture would embody a better defined and better >> documented SPI interface, including a way for comm. ports >> to be revealed to the client application through the API >> via platform-aware plugins. Similarly, native code used >> to access comm port in general could be handled more >> flexibly using a plugin model, whereby on any platform, >> multiple native modules could be in use simultaneously. >> >> Since there are now various ways serial ports can be implemented >> and accessed, modular comm. port JNI native libraries would be >> of benefit insofar as removing the burden of over-generalization >> from any single native component, or inversely, by relieving the >> implicit constraint that comm. drivers be accessed only via a >> monolithic mechanism, such as the UNIX vnode interface. >> >> paul.klissner at sun.com >> 6/10/06 >> >> I hope that is helpful! >> > > It would be nice to work with Sun to resolve those longstanding issues. > But it may not be practical unless the process goes as fast and painless > as the grandfathering of commapi did. > > Another option may be the old kaffe extensions that moved to gnu > classpathx. These don't have the native libraries but should provide > the 2.0 interface and the javax.comm.properties mechansim for SPI. > > http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Mon Aug 4 21:09:15 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 21:09:15 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? Message-ID: Hi Jim, I will not step into the javax.comm namespace without Sun's explicite permission. I fully understand the pain point you are trying to address. In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm Linux) - which remains an integral part of rxtx. At the time it was a win for Sun and rxtx. The Sun commapi license is/was fairly clear that rxtx should not step into that namespace. It made sense as Sun was active in that space and rxtx may go into another namespace - it was an experiment in working with Sun. This may sound silly looking at something that happened almost 10 years ago. In a community of respect which Sun helped create, there is no question about what to do. I hope eventually Sun will step up and do a right thing too. I agree that this is hurting the API more than helping it. There are also questions about how to replace the API in the long term which includes HID support which isn't going well so far. Others that can't even look at Sun's javax.comm today and can look at Kaffe's contribution to classpathx can easily work around such restrictions. On Mon, 4 Aug 2008, Jim Redman wrote: > Has there been any work/would it be possible, to layer a javacomm > look-alike on top of the GNU code? > > The goal is not to move the javax code forward, but to emulate the > "legacy" javax packages for people who still need this. > > Jim > > Trent Jarvi wrote: >> >> It would be nice to work with Sun to resolve those longstanding issues. >> But it may not be practical unless the process goes as fast and painless >> as the grandfathering of commapi did. >> >> Another option may be the old kaffe extensions that moved to gnu >> classpathx. These don't have the native libraries but should provide >> the 2.0 interface and the javax.comm.properties mechansim for SPI. >> >> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From florianmanschwetus at gmx.de Tue Aug 5 05:04:46 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 13:04:46 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: References: <48971C1F.9020806@gmx.de> Message-ID: <489833CE.1040801@gmx.de> Just look at sendCommand in this method I have to place a Thread.sleep(20) after each byte send to get working. Even the event based receive doesn't work fine but this could be may stupidness. The specifikation document (it is on the last pages of the manual) for the beamer could be found on: http://www.optoma.co.uk/support.aspx Florian Manschwetus Trent Jarvi schrieb: > > Hi Florian > > Sorry for the top post in advance. I worry you may not see my answer > under all your code :) > > I have not received this email before. This is 500k of code which I > don't have time to read. I can spend about 5 min on each hobby email > and still get to work in the morning. I have a couple suggestions for > how to get an answer. > > First, cut out your comments and extra code so you can demonstrate the > question (I might even glance and see what is wrong then). Don't go for > a working final product. Isolate the problem using a simple program and > then ask with that as an example. If I did what you just did, I'd have > to post 3/4 of a million lines of code :) > > Second, join the rxtx mail-list and ask there. This will give you 100x > more eyes. I'll also read and try to follow. > > -- > taj > > > > On Mon, 4 Aug 2008, Florian Manschwetus wrote: > >> It could be that my university account is blocked by filters so >> resending from here. >> >> >> Topic is to control Optoma HD80 beamer using rs232 serial chat. >> This code is able to detect power state and switch the beamer on / off. >> connected is the beamer using a digitus usb 2.0 serial adapter with an >> FT232 USB-Serial adapter the systems architecture is amd64. >> >> Please take a look in the sendCommand routine i have to place theire >> those Thread.sleep to get it working. >> Now the question is this correct or is there a better way to get this >> working correctly? >> >> In the javadoc coming with the install i found this: >> setBaudBase >> >> public boolean setBaudBase(int BaudBase) >> throws UnsupportedCommOperationException, >> java.io.IOException >> >> Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 >> before using. >> >> could this explain the error? >> I attached my java source and the protocol description for the beamer >> (available on vendor website). >> >> thx, >> Florian Manschwetus >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: TestRS232.java Type: text/x-java Size: 9143 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0026.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0027.bin From michael.erskine at ketech.com Tue Aug 5 05:53:49 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Tue, 5 Aug 2008 12:53:49 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489833CE.1040801@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> > Just look at sendCommand in this method I have to place a > Thread.sleep(20) after each byte send to get working. Even the event > based receive doesn't work fine but this could be may stupidness. Hi Florian, Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. Regards, Michael Erskine. From florianmanschwetus at gmx.de Tue Aug 5 07:28:15 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:28:15 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> Message-ID: <4898556F.8000208@gmx.de> Michael Erskine schrieb: >> Just look at sendCommand in this method I have to place a >> Thread.sleep(20) after each byte send to get working. Even the event >> based receive doesn't work fine but this could be may stupidness. > > Hi Florian, > > Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. > > Regards, > Michael Erskine. > Ok, sounds fine for the receiving problem. But why i have to wait after each byte when sending a command squence? (the for loop in send command) Florian > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/284f350c/attachment-0012.bin From florianmanschwetus at gmx.de Tue Aug 5 07:44:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:44:14 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <4898592E.2020908@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >>> Just look at sendCommand in this method I have to place a >>> Thread.sleep(20) after each byte send to get working. Even the event >>> based receive doesn't work fine but this could be may stupidness. >> >> Hi Florian, >> >> Yes, naturally you'll have to wait for a response from the other end. >> Why not wait for notification from the event thread perhaps using a >> BlockingDeque rather than your LinkedList. Generally I >> try to decouple all input and output streams: in your case your >> application is operating synchronously like the "expect" program >> (http://expect.nist.gov/) so waits (or timeouts) will need to be >> factored in. >> >> Regards, >> Michael Erskine. >> > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) > > Florian Furthermore there is this basic baud with this confusing javadoc entry: public boolean setBaudBase(int BaudBase) throws UnsupportedCommOperationException, java.io.IOException Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 before using. maybe this could explain something Florian >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/006c7425/attachment-0012.bin From jredman at ergotech.com Tue Aug 5 09:13:36 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 05 Aug 2008 09:13:36 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: Message-ID: <48986E20.3060104@ergotech.com> Trent, So two issues: 1) Technically I'm still not sure how easy/practical a layer would be. The problems are always classes like listeners, and wrapping returns of gnu.io classes. I really see it as a "delegate" type of concept. Any thoughts or ideas of the practicality of this approach? The idea is not to modify RXTX. 2) Javax. The javax namespace does seem to be in widespread use outside of Sun (the same is true for the java namespace). The classpath extensions, or some other location, should be interested in a JavaComm implementation even if it does have dependencies on RXTX. Would you have any philosophical objection to an approach like that? Of course, I suspect it might be better if someone with that authority at Sun would admit that the javax namespace is already in the wild and that there is no problem with it being used within RXTX. Jim Trent Jarvi wrote: > Hi Jim, > > I will not step into the javax.comm namespace without Sun's explicite > permission. I fully understand the pain point you are trying to address. > > In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm > Linux) - which remains an integral part of rxtx. At the time it was a win for > Sun and rxtx. > > The Sun commapi license is/was fairly clear that rxtx should not step into that > namespace. It made sense as Sun was active in that space and rxtx may go into > another namespace - it was an experiment in working with Sun. > > This may sound silly looking at something that happened almost 10 years ago. > In a community of respect which Sun helped create, there is no question about > what to do. I hope eventually Sun will step up and do a right thing too. > > I agree that this is hurting the API more than helping it. There are also > questions about how to replace the API in the long term which includes HID > support which isn't going well so far. > > Others that can't even look at Sun's javax.comm today and can look at Kaffe's > contribution to classpathx can easily work around such restrictions. > > On Mon, 4 Aug 2008, Jim Redman wrote: > >> Has there been any work/would it be possible, to layer a javacomm >> look-alike on top of the GNU code? >> >> The goal is not to move the javax code forward, but to emulate the >> "legacy" javax packages for people who still need this. >> >> Jim >> >> Trent Jarvi wrote: >>> It would be nice to work with Sun to resolve those longstanding issues. >>> But it may not be practical unless the process goes as fast and painless >>> as the grandfathering of commapi did. >>> >>> Another option may be the old kaffe extensions that moved to gnu >>> classpathx. These don't have the native libraries but should provide >>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>> >>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From sandeep at genevasoftech.com Tue Aug 5 11:18:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Tue, 05 Aug 2008 22:48:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <48988B6C.5080409@genevasoftech.com> Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. *-- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/ad20f1cb/attachment-0012.html From Martin.Oberhuber at windriver.com Tue Aug 5 13:30:17 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Tue, 5 Aug 2008 21:30:17 +0200 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Sandeep, shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on Sol7 but I've successfully run it on Sol9 and Sol10. Or is your request really about a native 64bit variant? I'm afraid that then you're out of luck since I think that quite a bit of RXTX is not yet ready for 64 bit. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Sandeep Kumar K Sent: Tuesday, August 05, 2008 7:19 PM To: rxtx at qbang.org Subject: [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so for Solaris 9 Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. -- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/81b7f988/attachment-0012.html From tjarvi at qbang.org Tue Aug 5 22:38:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 22:38:34 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 5 Aug 2008, Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built > on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid that > then > you're out of luck since I think that quite a bit of RXTX is not yet > ready > for 64 bit. > While rxtx-2.1-7 probably has problems, The CVS code should be OK for 64 bit Solaris. If it isn't, let me know and I'll find which patch is missing. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Aug 5 23:13:00 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 23:13:00 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48986E20.3060104@ergotech.com> References: <48986E20.3060104@ergotech.com> Message-ID: On Tue, 5 Aug 2008, Jim Redman wrote: > Trent, > > So two issues: > > 1) Technically I'm still not sure how easy/practical a layer would be. The > problems are always classes like listeners, and wrapping returns of gnu.io > classes. I really see it as a "delegate" type of concept. Any thoughts or > ideas of the practicality of this approach? The idea is not to modify RXTX. I have not put too much thought into this. I assume you want what rxtx 2.0 provided to tie into javax.comm implementations. More classes could be added to rxtx 2.1-7 for SPI support. Maintaining rxtx-2.0 could also be handed to someone if they like. > > 2) Javax. The javax namespace does seem to be in widespread use outside of > Sun (the same is true for the java namespace). The classpath extensions, or > some other location, should be interested in a JavaComm implementation even > if it does have dependencies on RXTX. Would you have any philosophical > objection to an approach like that? > No problems. Classpathx would be a possible place to do it. I'd suggest thinking twice about what this involves in practical terms. You would be wanting to revive the 2.0 API while Sun is at 3.0 and grandfathering the JSR. This undermines the main reason (established api) for using the javax.comm namespace and does not leave such a project in a good position. The only win I see here is maintaining support for applications that can't migrate namespaces. Not that that isn't important. At some point it is going to be less work to just edit the bytecode :) Such a javax.comm effort would also be signing up new projects that decided to use the work up for concerns they probably will not understand or expect. That probably isn't a good path to facilitate for new projects at this time. We will put a good faith effort to work well with others but keep in mind the project has limited bandwidth for such efforts. > Of course, I suspect it might be better if someone with that authority at Sun > would admit that the javax namespace is already in the wild and that there is > no problem with it being used within RXTX. > > Jim > > Trent Jarvi wrote: >> Hi Jim, >> >> I will not step into the javax.comm namespace without Sun's explicite >> permission. I fully understand the pain point you are trying to address. >> >> In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java >> Comm Linux) - which remains an integral part of rxtx. At the time it was a >> win for Sun and rxtx. >> >> The Sun commapi license is/was fairly clear that rxtx should not step into >> that namespace. It made sense as Sun was active in that space and rxtx may >> go into another namespace - it was an experiment in working with Sun. >> >> This may sound silly looking at something that happened almost 10 years >> ago. In a community of respect which Sun helped create, there is no >> question about what to do. I hope eventually Sun will step up and do a >> right thing too. >> >> I agree that this is hurting the API more than helping it. There are also >> questions about how to replace the API in the long term which includes HID >> support which isn't going well so far. >> >> Others that can't even look at Sun's javax.comm today and can look at >> Kaffe's contribution to classpathx can easily work around such >> restrictions. >> >> On Mon, 4 Aug 2008, Jim Redman wrote: >> >>> Has there been any work/would it be possible, to layer a javacomm >>> look-alike on top of the GNU code? >>> >>> The goal is not to move the javax code forward, but to emulate the >>> "legacy" javax packages for people who still need this. >>> >>> Jim >>> >>> Trent Jarvi wrote: >>>> It would be nice to work with Sun to resolve those longstanding issues. >>>> But it may not be practical unless the process goes as fast and painless >>>> as the grandfathering of commapi did. >>>> >>>> Another option may be the old kaffe extensions that moved to gnu >>>> classpathx. These don't have the native libraries but should provide >>>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>>> >>>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From sandeep at genevasoftech.com Wed Aug 6 00:03:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Wed, 06 Aug 2008 11:33:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: <48993EB8.30107@genevasoftech.com> Thank you Mr. Martin for your suggestion. The native file which is given in rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am getting the following error . Any suggestions to solve this issue. I am using Solaris SPARC 64 bit machine. ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) thrown while loading gnu.io.RXTXCommDriver Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(Unknown Source) at java.lang.ClassLoader.loadLibrary(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) at com.ReadFromModem.main(ReadFromModem.java:84) * * *Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid > that then > you're out of luck since I think that quite a bit of RXTX is not yet ready > for 64 bit. > > Cheers, > -- > *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > ------------------------------------------------------------------------ > *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On > Behalf Of *Sandeep Kumar K > *Sent:* Tuesday, August 05, 2008 7:19 PM > *To:* rxtx at qbang.org > *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so > for Solaris 9 > > Hi, > > Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 > bit machine. The librxtxSerial.so given in website is for Solaris 8. > > *-- > > Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/1e920343/attachment-0012.html From tjarvi at qbang.org Wed Aug 6 00:21:42 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 00:21:42 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <48993EB8.30107@genevasoftech.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> <48993EB8.30107@genevasoftech.com> Message-ID: Hi Sandeep You may be out of luck unless you can compile the 2.1 src in CVS (requires gnu make and gcc). But you could try the ToyBox(R)(TM) which is a collection of WiLdLy untested cross compiled 2.1-7 binaries covering everything from the ibm z series to embeded arm/ppc. To give an idea how poorly these are tested, I don't even know if z series machines have a serial port. ftp://www.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Solaris They should at least match the binary types. Actually, I think if you use the rxtx jar from CVS with that file, it should 'work' as the fix for 64 bits was in java not the native code. You could just cd rxtx*/src; javac *.java then jar -cf RXTXcomm.jar `find -name \*.class` to create the hybrid which will complain about version information a bit. On Wed, 6 Aug 2008, Sandeep Kumar K wrote: > Thank you Mr. Martin for your suggestion. The native file which is given in > rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am > getting the following error . > Any suggestions to solve this issue. > I am using Solaris SPARC 64 bit machine. > > ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar > java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 > (Possible cause: architecture word > width mismatch) thrown while loading gnu.io.RXTXCommDriver > Exception in thread "main" java.lang.UnsatisfiedLinkError: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF > class: ELFCLASS64 (Possible cause: > architecture word width mismatch) > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(Unknown Source) > at java.lang.ClassLoader.loadLibrary(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > at com.ReadFromModem.main(ReadFromModem.java:84) > > * > * > > *Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > > > Oberhuber, Martin wrote: >> Sandeep, >> shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse >> variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on >> Sol7 but I've successfully run it on Sol9 and Sol10. >> Or is your request really about a native 64bit variant? I'm afraid that >> then >> you're out of luck since I think that quite a bit of RXTX is not yet ready >> for 64 bit. >> Cheers, >> -- >> *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> ------------------------------------------------------------------------ >> *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On >> Behalf Of *Sandeep Kumar K >> *Sent:* Tuesday, August 05, 2008 7:19 PM >> *To:* rxtx at qbang.org >> *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so >> for Solaris 9 >> >> Hi, >> >> Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 >> bit machine. The librxtxSerial.so given in website is for Solaris 8. >> >> *-- >> Thanks & Regards >> >> Sandeep Kumar K >> Sr. Software Engineer >> Geneva Software Technologies >> Whitefield, Bangalore >> Mob : 9880193454* >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> From michael.erskine at ketech.com Wed Aug 6 01:39:28 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 6 Aug 2008 08:39:28 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Florian Manschwetus wrote: > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) Hi Florian, I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. Regards, Michael Erskine. From florianmanschwetus at gmx.de Wed Aug 6 02:53:16 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 06 Aug 2008 10:53:16 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Message-ID: <4899667C.6010706@gmx.de> Michael Erskine schrieb: > Florian Manschwetus wrote: >> Ok, sounds fine for the receiving problem. >> But why i have to wait after each byte when sending a command squence? >> (the for loop in send command) > > Hi Florian, > I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. > > Regards, > Michael Erskine. > correct with a terminal on the other end it works, my idea was that this basic baud has some influence. Could some one explain what it is for? Florian > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/c2b4fa84/attachment-0012.bin From rick_knight at rlknight.com Wed Aug 6 13:01:07 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:01:07 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F4F3.3020707@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > I have an application (Readerware) that uses RXTX with Javax to access the serial port. This used to work fine under previous Linux' and Java, but something has changed, I assume with Java itself , that is causing the application to fail with a link error. The application is not able to find librxtxSerialParallel.so. RXTX supplies librxtxSerial.so and librxtxParallel.so, but not librxtxSerialParallel.so. Where can I get librxtxSerialParallel.so, or do I need it? Is something else causing the lib to not be found? Thanks, Rick Knight From rick_knight at rlknight.com Wed Aug 6 13:17:55 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:17:55 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F8E3.5060400@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Thanks for the reply. The developer of the app I'm trying to use (Readerware) has sent me a copy of the comm.api and I've copied the library (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar into the proper places. When I try to run the application, I get this error... Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: /usr/lib/libSolarisSerialParallel.so: /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not little-endian (Possible cause: endianness mismatch) Caught java.lang.UnsatisfiedLinkError: com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I while loading driver com.sun.comm.SolarisDriver Is there a way around this error? Thanks again, Rick Knight From jlar310 at gmail.com Wed Aug 6 13:37:42 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 14:37:42 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899F8E3.5060400@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > The developer of the app I'm trying to use (Readerware) has sent me a > copy of the comm.api and I've copied the library > (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar > into the proper places. When I try to run the application, I get this > error... > > Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: > /usr/lib/libSolarisSerialParallel.so: > /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not > little-endian (Possible cause: endianness mismatch) > Caught java.lang.UnsatisfiedLinkError: > com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I > > while loading driver com.sun.comm.SolarisDriver > > Is there a way around this error? What host OS are you running? From your original post it looks like 32 bit Linux. The libSolarisSerialParallel.so file is for Sun Solaris and will vary depending on the underlying hardware architecture as well. Sorry for the double post Rick, but I failed to send this to the list the first time... -- Jeff From rick_knight at rlknight.com Wed Aug 6 13:44:29 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:44:29 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: <4899FF1D.9030504@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > > >> The developer of the app I'm trying to use (Readerware) has sent me a >> copy of the comm.api and I've copied the library >> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >> into the proper places. When I try to run the application, I get this >> error... >> >> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >> /usr/lib/libSolarisSerialParallel.so: >> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >> little-endian (Possible cause: endianness mismatch) >> Caught java.lang.UnsatisfiedLinkError: >> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >> >> while loading driver com.sun.comm.SolarisDriver >> >> Is there a way around this error? >> > > What host OS are you running? From your original post it looks like 32 > bit Linux. > > The libSolarisSerialParallel.so file is for Sun Solaris and will vary > depending on the underlying hardware architecture as well. > > I'm running Kubuntu Linux (debian based). It's 32 bit. Rick Knight From jlar310 at gmail.com Wed Aug 6 15:33:23 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 16:33:23 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > I don't think Sun did binary libraries for Linux in the 2.0 version. Can someone with more historical experience than I confirm that? I recently tried to port a Comm API application from Solaris sparc to Linux x86 and likewise could not get my hands on the binary libraries. I eventually just re-wrote the code to use the gnu namespace packages and rxtx 2.1. What I don't understand is why your application vendor does not provide everything you need to run their software. FYI: I have librxtxParallel.so and librxtxSerial.so installed at JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is /usr/java/default which is actually a softlink to /usr/java/jre1.6.0_05. -- Jeff From defiantlew at yahoo.com.au Wed Aug 6 16:29:33 2008 From: defiantlew at yahoo.com.au (Lew L) Date: Thu, 7 Aug 2008 08:29:33 +1000 Subject: [Rxtx] Sun's Comm API Documentation References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> Message-ID: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> As a matter of interest is the Sun Comm API documentation available somewhere? I have tried the Sun site but it seems to have been removed. Unless I have missed the documentation for RXTX? I javadocced the RXTX source but information (to me) is minimal. Somewhere I got the impression that the Sun Comm API docs is, or was, compatible with RXTX, what is the best docs to use in conjuntion with RXTX and where may the be available? Cheers Lew From rick_knight at rlknight.com Wed Aug 6 17:18:33 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:18:33 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A3149.4050306@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff I'm not sure if I posted this here or not, but when I try to build RXTX from source I get this install error... make all-am make[1]: Entering directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' make[1]: Nothing to be done for `all-am'. make[1]: Leaving directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 Can you tell me how to get past this error and get RXTX built and installed? Thanks, Rick From bboyes at systronix.com Wed Aug 6 17:40:12 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Wed, 06 Aug 2008 17:40:12 -0600 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: At 16:29 08/06/2008, Lew L wrote: >As a matter of interest is the Sun Comm API documentation available >somewhere? I have tried the Sun site but it seems to have been removed. It's in the file we have posted, link in prev email (sorry, in a huge hurry right now). Javadocs definitely there. >Unless I have missed the documentation for RXTX? I javadocced the RXTX >source but information (to me) is minimal. >Somewhere I got the impression that the Sun Comm API docs is, or was, >compatible with RXTX, what is the best docs to use in conjuntion with RXTX >and where may the be available? Yeah, this is one of my concerns/beefs. There is little documentation for RXTX and it isn't just the same as javaxcomm. I would be willing to help out writing docs for RXTX! Yes really... esp if we can fix the Bluetooth issues. best regards Bruce >Cheers >Lew > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx ------- WWW.SYSTRONIX.COM ---------- Real embedded Java and much more +1-801-534-1017 Salt Lake City, USA From rick_knight at rlknight.com Wed Aug 6 17:54:08 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:54:08 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A39A0.2090309@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff, I would like for my vendor to switch to rxtx 2.1. It would make things much easier for me. I'm not sure why he's still using the javax compatible code. He's a small operation. Re-writing the code to use gnu namespace sounds like a major overhaul. Was it? Thanks, Rick From tjarvi at qbang.org Wed Aug 6 21:35:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:35:12 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: >> >>> Jeff wrote: >>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>>> >>>> >>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things > much easier for me. I'm not sure why he's still using the javax > compatible code. He's a small operation. Re-writing the code to use gnu > namespace sounds like a major overhaul. Was it? > Hi Jeff, The changes are fairly mechanical. Imports need to change and any explicite use of the namespace needs to change such as catching an exception. The following script was made for maintaining rxtx 2.0 but can apply to other needs. It is in the contrib dir with rxtx source. #!/bin/sh # Don't use! :) # # Sat, 03 May 2003 16:45:08 Modifications from J?rg Weule # Create a ed-cmd for the change of one pattern # case $1 in gnu) X=g/javax_comm/s+javax_comm+gnu_io+g ;; javax) X=g/gnu_io/s+gnu_io+javax_comm+g ;; *) echo;echo;echo From the top rxtx directory run;echo;echo -e \\t./ChangePackage.sh gnu;echo -e \\t\\tor;echo -e \\t./ChangePackage.sh javax;echo;echo; exit 0 ;; esac # # ed will be used to keep the owner and mode of the files unchanged. # We have run the ed-script for the characters '.' '/' as well. # "tr _ $D" do the change. # find . -type f -a -print | grep -v $0 | (while read F ; do ( echo $X; echo $X| tr _ /; echo $X| tr _ .; echo w; echo q ) | ed $F 2>&1 >/dev/null done ) # # Now we do little changes at the Makefiles. Hope that all we need. # find . -name Makefile\* -a -print | (while read F ; do cat < References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: On Thu, 7 Aug 2008, Lew L wrote: > As a matter of interest is the Sun Comm API documentation available > somewhere? I have tried the Sun site but it seems to have been removed. > > Unless I have missed the documentation for RXTX? I javadocced the RXTX > source but information (to me) is minimal. > Somewhere I got the impression that the Sun Comm API docs is, or was, > compatible with RXTX, what is the best docs to use in conjuntion with RXTX > and where may the be available? > Hi Lew, The documentation on Sun's website is accurate. The changes that are problematic in 3.0 are on the backside which rxtx used to plug into. http://java.sun.com/products/javacomm/reference/api/index.html CommPortIdentifier may have some minor differences (judging by the authors notes). -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Aug 6 21:46:08 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:46:08 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > If javax.comm.properties is properly installed and you are using a 2.0 version of Sun's commapi with rxtx 2.0, you should not see the library attempt to load libSolarisSerialParallel.so. Sun CommAPI 3.0 will not work with any version of rxtx as it is hard coded to use the shared library. See the INSTALL file with rxtx-2.0 source for more help with the properties file. -- Trent Jarvi tjarvi at qbang.org From jlar310 at gmail.com Thu Aug 7 06:32:06 2008 From: jlar310 at gmail.com (Jeff) Date: Thu, 7 Aug 2008 07:32:06 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > Jeff wrote: >> >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >> wrote: >> >>> >>> Jeff wrote: >>> >>>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>> wrote: >>>> >>>> >>>> >>>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things much > easier for me. I'm not sure why he's still using the javax compatible code. > He's a small operation. Re-writing the code to use gnu namespace sounds like > a major overhaul. Was it? I found it quite easy. In fact, in order to accommodate the transition, I actually separated all of the code that deals directly with the Comm API or RXTX into a helper class. The helper class was then coded to use reflection to determine which library was available and then instantiate the necessary objects. No direct imports of either library are used. The main application just needs to get it's hands on the IO streams and need not deal directly with the libraries. Other programs may not be so simple... But this doesn't really help you unless your vendor forks over the source code... -- Jeff From rick_knight at rlknight.com Thu Aug 7 09:47:12 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Thu, 07 Aug 2008 08:47:12 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: <489B1900.10108@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >>> wrote: >>> >>> >>>> Jeff wrote: >>>> >>>> >>>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>>> copy of the comm.api and I've copied the library >>>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>>> into the proper places. When I try to run the application, I get this >>>>>> error... >>>>>> >>>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>>> /usr/lib/libSolarisSerialParallel.so: >>>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>>> little-endian (Possible cause: endianness mismatch) >>>>>> Caught java.lang.UnsatisfiedLinkError: >>>>>> >>>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>>> >>>>>> while loading driver com.sun.comm.SolarisDriver >>>>>> >>>>>> Is there a way around this error? >>>>>> >>>>>> >>>>>> >>>>> What host OS are you running? From your original post it looks like 32 >>>>> bit Linux. >>>>> >>>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>>> depending on the underlying hardware architecture as well. >>>>> >>>>> >>>>> >>>>> >>>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>>> >>>> >>>> >>> I don't think Sun did binary libraries for Linux in the 2.0 version. >>> Can someone with more historical experience than I confirm that? >>> >>> I recently tried to port a Comm API application from Solaris sparc to >>> Linux x86 and likewise could not get my hands on the binary libraries. >>> I eventually just re-wrote the code to use the gnu namespace packages >>> and rxtx 2.1. >>> >>> What I don't understand is why your application vendor does not >>> provide everything you need to run their software. >>> >>> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >>> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >>> /usr/java/default which is actually a softlink to >>> /usr/java/jre1.6.0_05. >>> >>> >>> >> Jeff, >> >> I would like for my vendor to switch to rxtx 2.1. It would make things much >> easier for me. I'm not sure why he's still using the javax compatible code. >> He's a small operation. Re-writing the code to use gnu namespace sounds like >> a major overhaul. Was it? >> > > I found it quite easy. In fact, in order to accommodate the > transition, I actually separated all of the code that deals directly > with the Comm API or RXTX into a helper class. The helper class was > then coded to use reflection to determine which library was available > and then instantiate the necessary objects. No direct imports of > either library are used. The main application just needs to get it's > hands on the IO streams and need not deal directly with the libraries. > Other programs may not be so simple... > > But this doesn't really help you unless your vendor forks over the > source code... > > Jeff, This may not help me directly, but I'm going to forward this thread to the vendor. I think he'll be open to making things work. Thanks again, Rick Knight From agusmunioz at gmail.com Thu Aug 7 16:39:51 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Thu, 7 Aug 2008 19:39:51 -0300 Subject: [Rxtx] How to send ack? Message-ID: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Hi, I'm still learning about serial communication and I have some doubts. I've got this question about how to do the following thing in rxtx. I have this hardware that connect to a PC using a serial port. These hardware receives data from a telephone line, proccess it, and then send it forward to the serial port. I've used a program named wincomm that shows what information is send it through the serial port and I have the nex behaviour: The hardware has a buffer where all data is stored, that cannot be sent it through the seria port. The program reads the first data send it by the hardware, and keep reading the same data always. There is a button in the application that says enable Ack, and when I click, then the hardware start to send all the stored information, and all the information is shown. I write a class, using rxtx that reads the serial port, and the same thing happens, it remains reading the same (first) data all the time. And I thing something like the enable Ack I'm missing. How can I do this enable Ack from my java code using rxtx? Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080807/e0a0f9a1/attachment-0010.html From ajmas at sympatico.ca Thu Aug 7 18:26:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 7 Aug 2008 20:26:41 -0400 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: <4BF42297-81E2-4BB8-A89F-1D43588379AE@sympatico.ca> On 6-Aug-08, at 19:40 , Bruce Boyes wrote: >> Unless I have missed the documentation for RXTX? I javadocced the >> RXTX >> source but information (to me) is minimal. >> Somewhere I got the impression that the Sun Comm API docs is, or was, >> compatible with RXTX, what is the best docs to use in conjuntion >> with RXTX >> and where may the be available? > > Yeah, this is one of my concerns/beefs. There is little documentation > for RXTX and it isn't just the same as javaxcomm. > > I would be willing to help out writing docs for RXTX! Yes really... > esp if we can fix the Bluetooth issues. If you want to contribute documentation then the best place to do that is the wiki. If there is anything missing or that could be improved on then please do so. If there are any points that you would like to see improved, for which you don't have the knowledge then ask on the mailing list for a volunteer. Andre From florianmanschwetus at gmx.de Fri Aug 8 03:04:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Fri, 08 Aug 2008 11:04:14 +0200 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Message-ID: <489C0C0E.2020401@gmx.de> Agustin Mu?oz schrieb: > Hi, I'm still learning about serial communication and I have some > doubts. I've got this question about how to do the following thing in rxtx. > I have this hardware that connect to a PC using a serial port. These > hardware receives data from a telephone line, proccess it, and then send > it forward to the serial port. I've used a program named wincomm that > shows what information is send it through the serial port and I have the > nex behaviour: > > The hardware has a buffer where all data is stored, that cannot be sent > it through the seria port. > The program reads the first data send it by the hardware, and keep > reading the same data always. > There is a button in the application that says enable Ack, and when I > click, then the hardware start to send all the stored information, and > all the information is shown. > > I write a class, using rxtx that reads the serial port, and the same > thing happens, it remains reading the same (first) data all the time. > And I thing something like the enable Ack I'm missing. > How can I do this enable Ack from my java code using rxtx? Afaik, a look at man ascii reveals: Okt Dez Hex Char 006 6 06 ACK So, i hope this will do the job: send(6); florian > > Thanks in advance > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/5b4965f8/attachment-0010.bin From agusmunioz at gmail.com Fri Aug 8 16:31:00 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 19:31:00 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <489C0C0E.2020401@gmx.de> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> Message-ID: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Hi Florian, thanks for the answer. By send(6) you mean to get the port OutputStream and write a 6? I try that but it didn't work. Any suggestion? Thanks On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < florianmanschwetus at gmx.de> wrote: > Agustin Mu?oz schrieb: > > Hi, I'm still learning about serial communication and I have some doubts. >> I've got this question about how to do the following thing in rxtx. >> I have this hardware that connect to a PC using a serial port. These >> hardware receives data from a telephone line, proccess it, and then send it >> forward to the serial port. I've used a program named wincomm that shows >> what information is send it through the serial port and I have the nex >> behaviour: >> >> The hardware has a buffer where all data is stored, that cannot be sent >> it through the seria port. >> The program reads the first data send it by the hardware, and keep reading >> the same data always. >> There is a button in the application that says enable Ack, and when I >> click, then the hardware start to send all the stored information, and all >> the information is shown. >> >> I write a class, using rxtx that reads the serial port, and the same thing >> happens, it remains reading the same (first) data all the time. And I thing >> something like the enable Ack I'm missing. >> How can I do this enable Ack from my java code using rxtx? >> > Afaik, a look at man ascii reveals: > Okt Dez Hex Char > 006 6 06 ACK > So, i hope this will do the job: > send(6); > > florian > >> >> Thanks in advance >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/7f3fba42/attachment-0009.html From agusmunioz at gmail.com Fri Aug 8 18:39:27 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 21:39:27 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Message-ID: <988288430808081739x7f9e7889id82591d5a9e2b4f6@mail.gmail.com> Ok, Florian, it works!! my problem was that I've been sending, through the OutputStream, the bytes of 6 as a string: out.write("6".getBytes()); but then I realized that you can write an int on an OuptuStream, so I tried that and It works: out.write(6); Thank you for the guidance!! On Fri, Aug 8, 2008 at 7:31 PM, Agustin Mu?oz wrote: > Hi Florian, thanks for the answer. By send(6) you mean to get the port > OutputStream and write a 6? > > I try that but it didn't work. > > Any suggestion? > > Thanks > > > On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < > florianmanschwetus at gmx.de> wrote: > >> Agustin Mu?oz schrieb: >> >> Hi, I'm still learning about serial communication and I have some doubts. >>> I've got this question about how to do the following thing in rxtx. >>> I have this hardware that connect to a PC using a serial port. These >>> hardware receives data from a telephone line, proccess it, and then send it >>> forward to the serial port. I've used a program named wincomm that shows >>> what information is send it through the serial port and I have the nex >>> behaviour: >>> >>> The hardware has a buffer where all data is stored, that cannot be sent >>> it through the seria port. >>> The program reads the first data send it by the hardware, and keep >>> reading the same data always. >>> There is a button in the application that says enable Ack, and when I >>> click, then the hardware start to send all the stored information, and all >>> the information is shown. >>> >>> I write a class, using rxtx that reads the serial port, and the same >>> thing happens, it remains reading the same (first) data all the time. And I >>> thing something like the enable Ack I'm missing. >>> How can I do this enable Ack from my java code using rxtx? >>> >> Afaik, a look at man ascii reveals: >> Okt Dez Hex Char >> 006 6 06 ACK >> So, i hope this will do the job: >> send(6); >> >> florian >> >>> >>> Thanks in advance >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/b918ab3d/attachment-0009.html From florianmanschwetus at gmx.de Sat Aug 9 00:45:43 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Sat, 09 Aug 2008 08:45:43 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4899667C.6010706@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> Message-ID: <489D3D17.9090209@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >> Florian Manschwetus wrote: >>> Ok, sounds fine for the receiving problem. >>> But why i have to wait after each byte when sending a command squence? >>> (the for loop in send command) >> >> Hi Florian, >> I'd imagine you probably don't! You could send all bytes in one go and >> RXTX would send them. The problem is most probably the other end: >> perhaps it has a really small buffer, some non-standard UART, or a >> crazy timing issue. If you attach a terminal to your output and send >> all the bytes of a command in one go they should appear no problem. >> >> Regards, >> Michael Erskine. >> > correct with a terminal on the other end it works, my idea was that this > basic baud has some influence. Could some one explain what it is for? > > Florian To make it more clear, my problem is that i can't use: outputStream.write(byte[]); => Beamer doesn't understand the sequence. (mostly no answer when he answers then *001) when i use this construct instead: for (int i = 0; i < command.length; i++) { this.outputStream.write(command[i]); try { Thread.sleep(25); } catch (InterruptedException e) { // TODO Auto-generated catch block e.printStackTrace(); } } it works nearly reliable. So what could it be? This Basic Baud is what exactly? Florian -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080809/692304ee/attachment-0009.bin From tjarvi at qbang.org Sat Aug 9 16:37:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Aug 2008 16:37:19 -0600 (MDT) Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489D3D17.9090209@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> <489D3D17.9090209@gmx.de> Message-ID: On Sat, 9 Aug 2008, Florian Manschwetus wrote: > Florian Manschwetus schrieb: >> Michael Erskine schrieb: >>> Florian Manschwetus wrote: >>>> Ok, sounds fine for the receiving problem. >>>> But why i have to wait after each byte when sending a command squence? >>>> (the for loop in send command) >>> >>> Hi Florian, >>> I'd imagine you probably don't! You could send all bytes in one go and >>> RXTX would send them. The problem is most probably the other end: perhaps >>> it has a really small buffer, some non-standard UART, or a crazy timing >>> issue. If you attach a terminal to your output and send all the bytes of a >>> command in one go they should appear no problem. >>> >>> Regards, >>> Michael Erskine. >>> >> correct with a terminal on the other end it works, my idea was that this >> basic baud has some influence. Could some one explain what it is for? >> >> Florian > To make it more clear, > my problem is that i can't use: > outputStream.write(byte[]); > => Beamer doesn't understand the sequence. (mostly no answer when he answers > then *001) > > when i use this construct instead: > > for (int i = 0; i < command.length; i++) { > this.outputStream.write(command[i]); > try { > Thread.sleep(25); > } catch (InterruptedException e) { > // TODO Auto-generated catch block > e.printStackTrace(); > } > } > > it works nearly reliable. > > So what could it be? This Basic Baud is what exactly? > I suspect you are using the 'moon protocol' and don't know it. RXTX enables this by default. The buffer on the other end is first in first out while reading. If the buffer is full, the bits are hand carried to the moon and burried. Then if the other side reads a couple bytes, two more bytes go into the buffer followed by more moon protocol. The resulting array of bytes the other side reads may appear to be scrambled until you go to the moon, get the bits and insert them in the right place. Flow control can prevent the default moon protocol and throttles the communiation by almost writing a byte at a time as need be. Hardware flow control is preferable but software flow control should also work. Read and write can appear to hang if the other side is not connected. This is why we don't enable them all the time. If you can't use flow control, you have to take care with the moon protocol and give the other side time to read. That is what your slower version of write is doing. -- Trent Jarvi tjarvi at qbang.org From rxtx at allenjb.me.uk Mon Aug 11 08:06:36 2008 From: rxtx at allenjb.me.uk (AllenJB) Date: Mon, 11 Aug 2008 15:06:36 +0100 Subject: [Rxtx] Disabling EV_RXFLAG Message-ID: <48A0476C.2090800@allenjb.me.uk> Hi all, I'm working with a device which does not use an EvtChar and need to disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an event mask of FD 01 00 00. The reference software I have uses FB 00 00 00. With the rxtx mask I get framing errors which I believe are caused when the EvtChar is received. Is there currently a way with rxtx (I've using rxtx from Java) to disable EV_RXFLAG? If not from Java, where would I start if I wanted to turn the EV_RXFLAG option off in the C code? I've had a grep of the rxtx source code, but I can't see where EV_RXFLAG is being set. Thanks in advance, AllenJB From tjarvi at qbang.org Mon Aug 11 14:17:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Aug 2008 14:17:27 -0600 (MDT) Subject: [Rxtx] Disabling EV_RXFLAG In-Reply-To: <48A0476C.2090800@allenjb.me.uk> References: <48A0476C.2090800@allenjb.me.uk> Message-ID: On Mon, 11 Aug 2008, AllenJB wrote: > Hi all, > > I'm working with a device which does not use an EvtChar and need to > disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an > event mask of FD 01 00 00. The reference software I have uses FB 00 00 > 00. With the rxtx mask I get framing errors which I believe are caused > when the EvtChar is received. > > Is there currently a way with rxtx (I've using rxtx from Java) to > disable EV_RXFLAG? > > If not from Java, where would I start if I wanted to turn the EV_RXFLAG > option off in the C code? I've had a grep of the rxtx source code, but I > can't see where EV_RXFLAG is being set. > > Thanks in advance, > > AllenJB Hi Allen, I'd look at termios.c::tcsetattr() and termios.c::FillDCB() -- Trent Jarvi tjarvi at qbang.org From superdadusa at gmail.com Tue Aug 12 13:57:32 2008 From: superdadusa at gmail.com (John Choi) Date: Tue, 12 Aug 2008 13:57:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. Message-ID: Hi all, Just let you all know I just start to learn Java. I have download the serial comm package and the source code from open source communities.. I was able to verify with the given message string via serial monitor. when the given message string sends to the serial port then the character return added to the end of string by default if I use "Hello World" however if I changed to something else other than "Hello, World" there is no character return add to the end of string. I thing the library download from rxtx.org has implemented for the special strings. I can do like "login\n" in the string message to make character return but I don't want to add this individual custom character for each command return in every static message string I send, Can any who have done this might help me? Basically, something like this,, Write and add function to the program write a command, Reads the respond from a serial device.. Function handles multiple messages, Write: "com open" Read: Welcome to my world" expected Write: "admin" Read: Password?, expected Write: "admin" Read: you are successfully login terminal, expected. And I need to add a separate function handler handles a character return add to the each command above. If anyone can help this I can do the reset? Thank you in advance, John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0005.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SerialIO.java Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0005.pl From Steffen.DETTMER at ingenico.com Wed Aug 13 02:16:38 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 13 Aug 2008 10:16:38 +0200 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: References: Message-ID: <20080813081638.GA25412@elberon.bln.de.ingenico.com> * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > I can do like "login\n" in the string message to make character > return but I don't want to add this individual custom character > for each command return in every static message string I send, and why not?! > Can any who have done this might help me? what's about with writing a small wrapper function adding the carriage return? However, this would be slow, because either you call write two times (very bad) or the string needs to be copied, \n appended and written (since you are using Java Performance probably isn't so critical). Personally I would write `"login\n"' and `username + "\n"' etc., because since it is part of the command it should be part of the command definition string. > Basically, something like this,, Write and add function to the program write > a command, Reads the respond from a serial device.. correctly reading a `line' is more difficult. If you cannot make assumptions about timeouts and/or you need to have low delay, you need to read byte wise. If you need to save CPU resources you might need to add some buffering layer that you can read byte-wise but that is reading blockwise with some small timeout (lets say for serial lines something around byte transmission time times three or so). > /* > * To change this template, choose Tools | Templates > * and open the template in the editor. > */ :) > package joliba; > > /** > * > * @author root > */ :) > // derived from SUN's examples in the javax.comm package > import java.io.*; > import java.util.*; > //import javax.comm.*; // for SUN's serial/parallel port libraries > import gnu.io.*; // for rxtxSerial library > > public class SerialIO implements Runnable, SerialPortEventListener { > static CommPortIdentifier portId; > static CommPortIdentifier saveportId; > static Enumeration portList; > InputStream inputStream; > SerialPort serialPort; > Thread readThread; You need a thread for your synchronous RPC-style protocol? > static String messageString = "Hello, world!"; > static OutputStream outputStream; > static boolean outputBufferEmptyFlag = false; > > public static void main(String[] args) { > boolean portFound = false; > String defaultPort; > > // determine the name of the serial port on several operating systems > String osname = System.getProperty("os.name","").toLowerCase(); > if ( osname.startsWith("windows") ) { > // windows > defaultPort = "COM1"; > } else if (osname.startsWith("linux")) { > // linux > defaultPort = "/dev/ttyS0"; > } else if ( osname.startsWith("mac") ) { > // mac > defaultPort = "????"; > } else { > System.out.println("Sorry, your operating system is not supported"); > return; > } Is such a construction recommended? Isn't there some abstraction (like COM1 working on any platform)? [...] > try { > // activate the OUTPUT_BUFFER_EMPTY notifier > serialPort.notifyOnOutputEmpty(true); > } catch (Exception e) { > System.out.println("Error setting event notification"); > System.out.println(e.toString()); > System.exit(-1); > } I doubt that -1 is defined, probably some 127 or so would be the result, maybe better simply `throw e'? > public void writetoport() { > System.out.println("Writing \""+messageString+"\" to "+serialPort.getName()); > try { > // write string to serial port > outputStream.write(messageString.getBytes()); > } catch (IOException e) {} > } maybe something like /** * Writes the given output string and an additional carriage * return to the current outputStream. */ public void writeStringToPort( /** The output string (without CR). */ String output ) throws IOException { String outputLine = output + "\n"; outputStream.write(outputLine.getBytes()); } ? > > public SerialIO() { > // initalize serial port > try { > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > } catch (PortInUseException e) {} if the port is in use, you continue? Wonder that this works in Java, I would assume serialPort beeing uninitialized which AFAIK is an error in Java. > try { > inputStream = serialPort.getInputStream(); > } catch (IOException e) {} > > try { > serialPort.addEventListener(this); > } catch (TooManyListenersException e) {} > > // activate the DATA_AVAILABLE notifier > serialPort.notifyOnDataAvailable(true); > > try { > // set port parameters > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > } catch (UnsupportedCommOperationException e) {} > > // start the read thread > readThread = new Thread(this); > readThread.start(); > > } I think in all those exception cases you can abort, because it is unlikely that ignoring those errors allow a successful continuation, so in this case maybe it would be better to add a throw clause to the method. > public void run() { > // first thing in the thread, we initialize the write operation > initwritetoport(); > try { > while (true) { > // write string to port, the serialEvent will read it > writetoport(); > Thread.sleep(1000); > } > } catch (InterruptedException e) {} > } Does this make sense? Your `SimpleReadApp' writes one and the same string each second? > public void serialEvent(SerialPortEvent event) { > switch (event.getEventType()) { > case SerialPortEvent.BI: > case SerialPortEvent.OE: > case SerialPortEvent.FE: > case SerialPortEvent.PE: > case SerialPortEvent.CD: > case SerialPortEvent.CTS: > case SerialPortEvent.DSR: > case SerialPortEvent.RI: > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > break; > case SerialPortEvent.DATA_AVAILABLE: > // we get here if data has been received > byte[] readBuffer = new byte[20]; > try { > // read data > while (inputStream.available() > 0) { > int numBytes = inputStream.read(readBuffer); > } > // print data > String result = new String(readBuffer); > System.out.println("Read: "+result); > } catch (IOException e) {} I doubt that this is correct. I would assume you will get a 20 bytes result always, if more bytes would be available they would be printed in a second line but if less bytes are read I'd assume that the buffer/result contains zero bytes from implicite readBuffer contents initialisation (zero is no string terminator in Java AFAIK). > break; > } > } > } oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From florianmanschwetus at gmx.de Wed Aug 13 06:09:31 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 13 Aug 2008 14:09:31 +0200 Subject: [Rxtx] someone has seen such errors? Message-ID: <48A2CEFB.90007@gmx.de> I mean my communication mostly works, but it is far from perfect could this be the reason? Florian Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/949b9947/attachment-0005.bin From superdadusa at gmail.com Wed Aug 13 08:40:32 2008 From: superdadusa at gmail.com (John Choi) Date: Wed, 13 Aug 2008 08:40:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: <20080813081638.GA25412@elberon.bln.de.ingenico.com> References: <20080813081638.GA25412@elberon.bln.de.ingenico.com> Message-ID: Thank you so much Steffen and I will try that suggestion. John On 8/13/08, Steffen DETTMER wrote: > > * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > > I can do like "login\n" in the string message to make character > > return but I don't want to add this individual custom character > > for each command return in every static message string I send, > > and why not?! > > > Can any who have done this might help me? > > what's about with writing a small wrapper function adding the > carriage return? > However, this would be slow, because either you call write two > times (very bad) or the string needs to be copied, \n appended > and written (since you are using Java Performance probably isn't > so critical). > > Personally I would write `"login\n"' and `username + "\n"' etc., > because since it is part of the command it should be part of the > command definition string. > > > Basically, something like this,, Write and add function to the program > write > > a command, Reads the respond from a serial device.. > > correctly reading a `line' is more difficult. If you cannot make > assumptions about timeouts and/or you need to have low delay, you > need to read byte wise. If you need to save CPU resources you > might need to add some buffering layer that you can read > byte-wise but that is reading blockwise with some small timeout > (lets say for serial lines something around byte transmission > time times three or so). > > > /* > > * To change this template, choose Tools | Templates > > * and open the template in the editor. > > */ > > :) > > > package joliba; > > > > /** > > * > > * @author root > > */ > > :) > > > // derived from SUN's examples in the javax.comm package > > import java.io.*; > > import java.util.*; > > //import javax.comm.*; // for SUN's serial/parallel port libraries > > import gnu.io.*; // for rxtxSerial library > > > > public class SerialIO implements Runnable, SerialPortEventListener { > > static CommPortIdentifier portId; > > static CommPortIdentifier saveportId; > > static Enumeration portList; > > InputStream inputStream; > > SerialPort serialPort; > > Thread readThread; > > You need a thread for your synchronous RPC-style protocol? > > > static String messageString = "Hello, world!"; > > static OutputStream outputStream; > > static boolean outputBufferEmptyFlag = false; > > > > public static void main(String[] args) { > > boolean portFound = false; > > String defaultPort; > > > > // determine the name of the serial port on several operating > systems > > String osname = System.getProperty("os.name","").toLowerCase(); > > if ( osname.startsWith("windows") ) { > > // windows > > defaultPort = "COM1"; > > } else if (osname.startsWith("linux")) { > > // linux > > defaultPort = "/dev/ttyS0"; > > } else if ( osname.startsWith("mac") ) { > > // mac > > defaultPort = "????"; > > } else { > > System.out.println("Sorry, your operating system is not > supported"); > > return; > > } > > Is such a construction recommended? Isn't there some abstraction > (like COM1 working on any platform)? > > [...] > > try { > > // activate the OUTPUT_BUFFER_EMPTY notifier > > serialPort.notifyOnOutputEmpty(true); > > } catch (Exception e) { > > System.out.println("Error setting event notification"); > > System.out.println(e.toString()); > > System.exit(-1); > > } > > I doubt that -1 is defined, probably some 127 or so would be the > result, maybe better simply `throw e'? > > > public void writetoport() { > > System.out.println("Writing \""+messageString+"\" to > "+serialPort.getName()); > > try { > > // write string to serial port > > outputStream.write(messageString.getBytes()); > > } catch (IOException e) {} > > } > > maybe something like > > /** > * Writes the given output string and an additional carriage > * return to the current outputStream. > */ > public void > writeStringToPort( > /** The output string (without CR). */ > String output > ) throws IOException > { > String outputLine = output + "\n"; > outputStream.write(outputLine.getBytes()); > } > > ? > > > > > public SerialIO() { > > // initalize serial port > > try { > > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > > } catch (PortInUseException e) {} > > if the port is in use, you continue? Wonder that this works in > Java, I would assume serialPort beeing uninitialized which AFAIK > is an error in Java. > > > try { > > inputStream = serialPort.getInputStream(); > > } catch (IOException e) {} > > > > try { > > serialPort.addEventListener(this); > > } catch (TooManyListenersException e) {} > > > > // activate the DATA_AVAILABLE notifier > > serialPort.notifyOnDataAvailable(true); > > > > try { > > // set port parameters > > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > } catch (UnsupportedCommOperationException e) {} > > > > // start the read thread > > readThread = new Thread(this); > > readThread.start(); > > > > } > > I think in all those exception cases you can abort, because it is > unlikely that ignoring those errors allow a successful > continuation, so in this case maybe it would be better to add a > throw clause to the method. > > > public void run() { > > // first thing in the thread, we initialize the write operation > > initwritetoport(); > > try { > > while (true) { > > // write string to port, the serialEvent will read it > > writetoport(); > > Thread.sleep(1000); > > } > > } catch (InterruptedException e) {} > > } > > Does this make sense? Your `SimpleReadApp' writes one and the > same string each second? > > > public void serialEvent(SerialPortEvent event) { > > switch (event.getEventType()) { > > case SerialPortEvent.BI: > > case SerialPortEvent.OE: > > case SerialPortEvent.FE: > > case SerialPortEvent.PE: > > case SerialPortEvent.CD: > > case SerialPortEvent.CTS: > > case SerialPortEvent.DSR: > > case SerialPortEvent.RI: > > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > > break; > > case SerialPortEvent.DATA_AVAILABLE: > > // we get here if data has been received > > byte[] readBuffer = new byte[20]; > > try { > > // read data > > while (inputStream.available() > 0) { > > int numBytes = inputStream.read(readBuffer); > > } > > // print data > > String result = new String(readBuffer); > > System.out.println("Read: "+result); > > } catch (IOException e) {} > > I doubt that this is correct. I would assume you will get a 20 > bytes result always, if more bytes would be available they would > be printed in a second line but if less bytes are read I'd assume > that the buffer/result contains zero bytes from implicite > readBuffer contents initialisation (zero is no string terminator > in Java AFAIK). > > > break; > > } > > } > > } > > oki, > > Steffen > > About Ingenico Throughout the world businesses rely on Ingenico for secure > and expedient electronic transaction acceptance. Ingenico products leverage > proven technology, established standards and unparalleled ergonomics to > provide optimal reliability, versatility and usability. This comprehensive > range of products is complemented by a global array of services and > partnerships, enabling businesses in a number of vertical sectors to accept > transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged > information. If you are not the addressee or authorized to receive this for > the addressee, you must not use, copy, disclose or take any action based on > this message or any information herein. If you have received this message in > error, please advise the sender immediately by reply e-mail and delete this > message. Thank you for your cooperation. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/73c4135c/attachment-0004.html From ajmas at sympatico.ca Sat Aug 16 07:15:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 09:15:41 -0400 Subject: [Rxtx] someone has seen such errors? In-Reply-To: <48A2CEFB.90007@gmx.de> References: <48A2CEFB.90007@gmx.de> Message-ID: <43B5E8DA-1D93-4D90-809B-AAF35FF724C5@sympatico.ca> On 13-Aug-08, at 08:09 , Florian Manschwetus wrote: > I mean my communication mostly works, but it is far from perfect > could this be the reason? > > Florian > > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control Judging by the error messages this looks related to the driver you are using. Do a search for the following string with you favourite search engine, it should turn up a few hits: ftdi_set_termios FAILED to set databits/stopbits/parity Andre From ajmas at sympatico.ca Sat Aug 16 19:12:04 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 21:12:04 -0400 Subject: [Rxtx] Using SerialPortEvent? Message-ID: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Hi, Could someone tell me how I should be using the SerialPortEvent? Am I meant to be waiting for data and then simply reading from the inputstream? If this is the case why no just block on an inputstream read? Andr? From tjarvi at qbang.org Sat Aug 16 19:41:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 16 Aug 2008 19:41:13 -0600 (MDT) Subject: [Rxtx] Using SerialPortEvent? In-Reply-To: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> References: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Message-ID: On Sat, 16 Aug 2008, Andre-John Mas wrote: > Hi, > > Could someone tell me how I should be using the SerialPortEvent? Am I > meant to be waiting for data and then simply reading from the > inputstream? If this is the case why no just block on an inputstream > read? > Polling for data is fine also. It really depends upon what you are trying to do. For instance, if you require x bytes before reading, you can start polling after data is available. If you read on the same thread as your GUI and are waiting for data in a read, the results may be less than desirable. Java programming is 'usually' event driven rather than polling based. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sat Aug 16 20:10:39 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 22:10:39 -0400 Subject: [Rxtx] Using SerialPortEvent? In-Reply-To: References: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Message-ID: <3E495D4C-BB28-4845-A6AB-984C9A826BDF@sympatico.ca> On 16-Aug-08, at 21:41 , Trent Jarvi wrote: > On Sat, 16 Aug 2008, Andre-John Mas wrote: > >> Hi, >> >> Could someone tell me how I should be using the SerialPortEvent? Am I >> meant to be waiting for data and then simply reading from the >> inputstream? If this is the case why no just block on an inputstream >> read? >> > > Polling for data is fine also. It really depends upon what you are > trying to do. For instance, if you require x bytes before reading, > you can start polling after data is available. If you read on the > same thread as your GUI and are waiting for data in a read, the > results may be less than desirable. > > Java programming is 'usually' event driven rather than polling based. Sounds good. I thought I would use this opportunity to provide a event based version of the TwoWaySerialComm example. Could you just validate it before I add it to the Wiki: package ajmas74.experimental; import gnu.io.CommPort; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; import gnu.io.SerialPortEvent; import gnu.io.SerialPortEventListener; import java.io.IOException; import java.io.InputStream; import java.io.OutputStream; /** * This version of the TwoWaySerialComm example makes use of the * SerialPortEventListener to avoid polling. * * @author ajmas * */ public class TwoWaySerialComm { public TwoWaySerialComm() { super(); } void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { CommPort commPort = portIdentifier.open(this.getClass().getName(),2000); if ( commPort instanceof SerialPort ) { SerialPort serialPort = (SerialPort) commPort; serialPort .setSerialPortParams (57600 ,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); (new Thread(new SerialWriter(out))).start(); serialPort.addEventListener(new SerialReader(in)); } else { System.out.println("Error: Only serial ports are handled by this example."); } } } /** * Handles the input coming from the serial port. A new line character * is treated as the end of a block in this example. */ public static class SerialReader implements SerialPortEventListener { private InputStream in; private byte[] buffer = new byte[1024]; public SerialReader ( InputStream in ) { this.in = in; } public void serialEvent(SerialPortEvent arg0) { int data; try { int len = 0; while ( ( data = in.read()) > -1 ) { if ( data != '\n' ) { break; } buffer[len++] = (byte) data; } System.out.print(new String(buffer,0,len)); } catch ( IOException e ) { e.printStackTrace(); System.exit(-1); } } } /** */ public static class SerialWriter implements Runnable { OutputStream out; public SerialWriter ( OutputStream out ) { this.out = out; } public void run () { try { int c = 0; while ( ( c = System.in.read()) > -1 ) { this.out.write(c); } } catch ( IOException e ) { e.printStackTrace(); System.exit(-1); } } } public static void main ( String[] args ) { try { (new TwoWaySerialComm()).connect("COM3"); } catch ( Exception e ) { e.printStackTrace(); } } } From rick_knight at rlknight.com Mon Aug 4 13:25:10 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Mon, 04 Aug 2008 12:25:10 -0700 Subject: [Rxtx] Sun's Comm API? Message-ID: <48975796.4010600@rlknight.com> I have an application that requires the javax compatible version of RXTX and Sun's comm api. I've been able to download and extract the version of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api anywhere. Can someone tell me where I can find it? Or maybe send me a copy? Also, when I try to build RXTX, configure and make complete successfully but make install failes with this error libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 I've never come accross this error before. How can I get past it? Thanks, Rick From bboyes at systronix.com Mon Aug 4 19:10:01 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:10:01 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48975796.4010600@rlknight.com> References: <48975796.4010600@rlknight.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/cb9c6167/attachment-0014.html From bboyes at systronix.com Mon Aug 4 19:12:37 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:12:37 -0600 Subject: [Rxtx] Towards an RXTX release - CSR BT/USB chipset In-Reply-To: <488FB7E7.8000802@gmail.com> References: <460801A4097E3D4CA04CC64EE648584806C56CF0@ism-mail03.corp.ad.wrs.com> <13557-75390@sneakemail.com> <20980-23424@sneakemail.com> <488FB7E7.8000802@gmail.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/52236088/attachment-0014.html From tjarvi at qbang.org Mon Aug 4 19:42:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 19:42:21 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: On Mon, 4 Aug 2008, Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: > I have an application that requires the javax compatible > version of RXTX > and Sun's comm api. I've been able to download and extract > the version > of RXTX that I need (2.0-7pre2) but I can't find Sun's camm > api > anywhere. Can someone tell me where I can find it? Or maybe > send me a > > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm port > support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have just > a ZIP with only the .class JAR file - no source or docs), has a readme > with these comments: > > This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release.? The 2.0.3 release itself is > no longer distributed.? comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project.? The RxTx project (http://www.rxtx.org ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org) was opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support.? Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins.? Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > ? > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > I hope that is helpful! > It would be nice to work with Sun to resolve those longstanding issues. But it may not be practical unless the process goes as fast and painless as the grandfathering of commapi did. Another option may be the old kaffe extensions that moved to gnu classpathx. These don't have the native libraries but should provide the 2.0 interface and the javax.comm.properties mechansim for SPI. http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Mon Aug 4 20:23:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Mon, 04 Aug 2008 20:23:57 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4897B9BD.5070809@ergotech.com> Has there been any work/would it be possible, to layer a javacomm look-alike on top of the GNU code? The goal is not to move the javax code forward, but to emulate the "legacy" javax packages for people who still need this. Jim Trent Jarvi wrote: > On Mon, 4 Aug 2008, Bruce Boyes wrote: > >> At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible >> version of RXTX >> and Sun's comm api. I've been able to download and extract >> the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm >> api >> anywhere. Can someone tell me where I can find it? Or maybe >> send me a >> >> >> javaxcomm has had a sort of on-again off-again history. The windoze >> version has been languishing for years (literally) but there are newer >> versions for other OS's. >> >> We try to keep links on one of our help pages current: >> http://www.practicalembeddedjava.com/tools/javatools_list.html >> which gets you to here: >> http://java.sun.com/products/javacomm/ >> where it says in fact they no longer even support Windows and Mac: >> "Implementations of the API are currently available for Solaris SPARC, >> Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so >> someone could support it. But I guess that's part of the reason RXTX >> exists! >> >> So one of Sun's own products, SunSPOT, has to use RXTX to get comm port >> support. >> >> The version we use is 2.0 from 11/15/1998. I have posted it on our >> website, which is within the terms of the license agreement contained >> therein (as I understand it). >> >> The last version of javaxcomm for Windows, 2.0.3, (for which I have just >> a ZIP with only the .class JAR file - no source or docs), has a readme >> with these comments: >> >> This distribution contains the comm.jar file original part >> of the COMMAPI 2.0.3 release. The 2.0.3 release itself is >> no longer distributed. comm.jar, which contains the comm >> API java class files (eg. Sun's binary implementation of the >> interface classes), is being made available, unsupported, >> with no obligation to fix bugs, at the request of the RXTX >> project. The RxTx project (http://www.rxtx.org ), uses the >> comm.jar class files, but provides their own native library >> components to provide support for other platforms. >> >> The 2.0.3 comm.jar is being provided in this way because >> as of COMMAPI 3.x, the java binary implementation forked and >> became incompatible with the RxTx project's native code. >> Due to the lack of a clear business case, and to resource >> constraints, no additional resources are being >> provided to provide an alternative engineering solution >> at the time of writing. >> >> RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: >> >> Ultimately the COMMAPI would be better served if a Java >> Community Process JSR (http://www.jcp.org) was opened and >> the COMMAPI was rearchitected to provide a more pluggable >> framework to improve cross-platform support. Such an >> architecture would embody a better defined and better >> documented SPI interface, including a way for comm. ports >> to be revealed to the client application through the API >> via platform-aware plugins. Similarly, native code used >> to access comm port in general could be handled more >> flexibly using a plugin model, whereby on any platform, >> multiple native modules could be in use simultaneously. >> >> Since there are now various ways serial ports can be implemented >> and accessed, modular comm. port JNI native libraries would be >> of benefit insofar as removing the burden of over-generalization >> from any single native component, or inversely, by relieving the >> implicit constraint that comm. drivers be accessed only via a >> monolithic mechanism, such as the UNIX vnode interface. >> >> paul.klissner at sun.com >> 6/10/06 >> >> I hope that is helpful! >> > > It would be nice to work with Sun to resolve those longstanding issues. > But it may not be practical unless the process goes as fast and painless > as the grandfathering of commapi did. > > Another option may be the old kaffe extensions that moved to gnu > classpathx. These don't have the native libraries but should provide > the 2.0 interface and the javax.comm.properties mechansim for SPI. > > http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Mon Aug 4 21:09:15 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 21:09:15 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? Message-ID: Hi Jim, I will not step into the javax.comm namespace without Sun's explicite permission. I fully understand the pain point you are trying to address. In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm Linux) - which remains an integral part of rxtx. At the time it was a win for Sun and rxtx. The Sun commapi license is/was fairly clear that rxtx should not step into that namespace. It made sense as Sun was active in that space and rxtx may go into another namespace - it was an experiment in working with Sun. This may sound silly looking at something that happened almost 10 years ago. In a community of respect which Sun helped create, there is no question about what to do. I hope eventually Sun will step up and do a right thing too. I agree that this is hurting the API more than helping it. There are also questions about how to replace the API in the long term which includes HID support which isn't going well so far. Others that can't even look at Sun's javax.comm today and can look at Kaffe's contribution to classpathx can easily work around such restrictions. On Mon, 4 Aug 2008, Jim Redman wrote: > Has there been any work/would it be possible, to layer a javacomm > look-alike on top of the GNU code? > > The goal is not to move the javax code forward, but to emulate the > "legacy" javax packages for people who still need this. > > Jim > > Trent Jarvi wrote: >> >> It would be nice to work with Sun to resolve those longstanding issues. >> But it may not be practical unless the process goes as fast and painless >> as the grandfathering of commapi did. >> >> Another option may be the old kaffe extensions that moved to gnu >> classpathx. These don't have the native libraries but should provide >> the 2.0 interface and the javax.comm.properties mechansim for SPI. >> >> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From florianmanschwetus at gmx.de Tue Aug 5 05:04:46 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 13:04:46 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: References: <48971C1F.9020806@gmx.de> Message-ID: <489833CE.1040801@gmx.de> Just look at sendCommand in this method I have to place a Thread.sleep(20) after each byte send to get working. Even the event based receive doesn't work fine but this could be may stupidness. The specifikation document (it is on the last pages of the manual) for the beamer could be found on: http://www.optoma.co.uk/support.aspx Florian Manschwetus Trent Jarvi schrieb: > > Hi Florian > > Sorry for the top post in advance. I worry you may not see my answer > under all your code :) > > I have not received this email before. This is 500k of code which I > don't have time to read. I can spend about 5 min on each hobby email > and still get to work in the morning. I have a couple suggestions for > how to get an answer. > > First, cut out your comments and extra code so you can demonstrate the > question (I might even glance and see what is wrong then). Don't go for > a working final product. Isolate the problem using a simple program and > then ask with that as an example. If I did what you just did, I'd have > to post 3/4 of a million lines of code :) > > Second, join the rxtx mail-list and ask there. This will give you 100x > more eyes. I'll also read and try to follow. > > -- > taj > > > > On Mon, 4 Aug 2008, Florian Manschwetus wrote: > >> It could be that my university account is blocked by filters so >> resending from here. >> >> >> Topic is to control Optoma HD80 beamer using rs232 serial chat. >> This code is able to detect power state and switch the beamer on / off. >> connected is the beamer using a digitus usb 2.0 serial adapter with an >> FT232 USB-Serial adapter the systems architecture is amd64. >> >> Please take a look in the sendCommand routine i have to place theire >> those Thread.sleep to get it working. >> Now the question is this correct or is there a better way to get this >> working correctly? >> >> In the javadoc coming with the install i found this: >> setBaudBase >> >> public boolean setBaudBase(int BaudBase) >> throws UnsupportedCommOperationException, >> java.io.IOException >> >> Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 >> before using. >> >> could this explain the error? >> I attached my java source and the protocol description for the beamer >> (available on vendor website). >> >> thx, >> Florian Manschwetus >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: TestRS232.java Type: text/x-java Size: 9143 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0028.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0029.bin From michael.erskine at ketech.com Tue Aug 5 05:53:49 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Tue, 5 Aug 2008 12:53:49 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489833CE.1040801@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> > Just look at sendCommand in this method I have to place a > Thread.sleep(20) after each byte send to get working. Even the event > based receive doesn't work fine but this could be may stupidness. Hi Florian, Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. Regards, Michael Erskine. From florianmanschwetus at gmx.de Tue Aug 5 07:28:15 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:28:15 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> Message-ID: <4898556F.8000208@gmx.de> Michael Erskine schrieb: >> Just look at sendCommand in this method I have to place a >> Thread.sleep(20) after each byte send to get working. Even the event >> based receive doesn't work fine but this could be may stupidness. > > Hi Florian, > > Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. > > Regards, > Michael Erskine. > Ok, sounds fine for the receiving problem. But why i have to wait after each byte when sending a command squence? (the for loop in send command) Florian > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/284f350c/attachment-0013.bin From florianmanschwetus at gmx.de Tue Aug 5 07:44:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:44:14 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <4898592E.2020908@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >>> Just look at sendCommand in this method I have to place a >>> Thread.sleep(20) after each byte send to get working. Even the event >>> based receive doesn't work fine but this could be may stupidness. >> >> Hi Florian, >> >> Yes, naturally you'll have to wait for a response from the other end. >> Why not wait for notification from the event thread perhaps using a >> BlockingDeque rather than your LinkedList. Generally I >> try to decouple all input and output streams: in your case your >> application is operating synchronously like the "expect" program >> (http://expect.nist.gov/) so waits (or timeouts) will need to be >> factored in. >> >> Regards, >> Michael Erskine. >> > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) > > Florian Furthermore there is this basic baud with this confusing javadoc entry: public boolean setBaudBase(int BaudBase) throws UnsupportedCommOperationException, java.io.IOException Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 before using. maybe this could explain something Florian >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/006c7425/attachment-0013.bin From jredman at ergotech.com Tue Aug 5 09:13:36 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 05 Aug 2008 09:13:36 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: Message-ID: <48986E20.3060104@ergotech.com> Trent, So two issues: 1) Technically I'm still not sure how easy/practical a layer would be. The problems are always classes like listeners, and wrapping returns of gnu.io classes. I really see it as a "delegate" type of concept. Any thoughts or ideas of the practicality of this approach? The idea is not to modify RXTX. 2) Javax. The javax namespace does seem to be in widespread use outside of Sun (the same is true for the java namespace). The classpath extensions, or some other location, should be interested in a JavaComm implementation even if it does have dependencies on RXTX. Would you have any philosophical objection to an approach like that? Of course, I suspect it might be better if someone with that authority at Sun would admit that the javax namespace is already in the wild and that there is no problem with it being used within RXTX. Jim Trent Jarvi wrote: > Hi Jim, > > I will not step into the javax.comm namespace without Sun's explicite > permission. I fully understand the pain point you are trying to address. > > In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm > Linux) - which remains an integral part of rxtx. At the time it was a win for > Sun and rxtx. > > The Sun commapi license is/was fairly clear that rxtx should not step into that > namespace. It made sense as Sun was active in that space and rxtx may go into > another namespace - it was an experiment in working with Sun. > > This may sound silly looking at something that happened almost 10 years ago. > In a community of respect which Sun helped create, there is no question about > what to do. I hope eventually Sun will step up and do a right thing too. > > I agree that this is hurting the API more than helping it. There are also > questions about how to replace the API in the long term which includes HID > support which isn't going well so far. > > Others that can't even look at Sun's javax.comm today and can look at Kaffe's > contribution to classpathx can easily work around such restrictions. > > On Mon, 4 Aug 2008, Jim Redman wrote: > >> Has there been any work/would it be possible, to layer a javacomm >> look-alike on top of the GNU code? >> >> The goal is not to move the javax code forward, but to emulate the >> "legacy" javax packages for people who still need this. >> >> Jim >> >> Trent Jarvi wrote: >>> It would be nice to work with Sun to resolve those longstanding issues. >>> But it may not be practical unless the process goes as fast and painless >>> as the grandfathering of commapi did. >>> >>> Another option may be the old kaffe extensions that moved to gnu >>> classpathx. These don't have the native libraries but should provide >>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>> >>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From sandeep at genevasoftech.com Tue Aug 5 11:18:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Tue, 05 Aug 2008 22:48:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <48988B6C.5080409@genevasoftech.com> Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. *-- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/ad20f1cb/attachment-0013.html From Martin.Oberhuber at windriver.com Tue Aug 5 13:30:17 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Tue, 5 Aug 2008 21:30:17 +0200 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Sandeep, shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on Sol7 but I've successfully run it on Sol9 and Sol10. Or is your request really about a native 64bit variant? I'm afraid that then you're out of luck since I think that quite a bit of RXTX is not yet ready for 64 bit. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Sandeep Kumar K Sent: Tuesday, August 05, 2008 7:19 PM To: rxtx at qbang.org Subject: [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so for Solaris 9 Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. -- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/81b7f988/attachment-0013.html From tjarvi at qbang.org Tue Aug 5 22:38:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 22:38:34 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 5 Aug 2008, Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built > on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid that > then > you're out of luck since I think that quite a bit of RXTX is not yet > ready > for 64 bit. > While rxtx-2.1-7 probably has problems, The CVS code should be OK for 64 bit Solaris. If it isn't, let me know and I'll find which patch is missing. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Aug 5 23:13:00 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 23:13:00 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48986E20.3060104@ergotech.com> References: <48986E20.3060104@ergotech.com> Message-ID: On Tue, 5 Aug 2008, Jim Redman wrote: > Trent, > > So two issues: > > 1) Technically I'm still not sure how easy/practical a layer would be. The > problems are always classes like listeners, and wrapping returns of gnu.io > classes. I really see it as a "delegate" type of concept. Any thoughts or > ideas of the practicality of this approach? The idea is not to modify RXTX. I have not put too much thought into this. I assume you want what rxtx 2.0 provided to tie into javax.comm implementations. More classes could be added to rxtx 2.1-7 for SPI support. Maintaining rxtx-2.0 could also be handed to someone if they like. > > 2) Javax. The javax namespace does seem to be in widespread use outside of > Sun (the same is true for the java namespace). The classpath extensions, or > some other location, should be interested in a JavaComm implementation even > if it does have dependencies on RXTX. Would you have any philosophical > objection to an approach like that? > No problems. Classpathx would be a possible place to do it. I'd suggest thinking twice about what this involves in practical terms. You would be wanting to revive the 2.0 API while Sun is at 3.0 and grandfathering the JSR. This undermines the main reason (established api) for using the javax.comm namespace and does not leave such a project in a good position. The only win I see here is maintaining support for applications that can't migrate namespaces. Not that that isn't important. At some point it is going to be less work to just edit the bytecode :) Such a javax.comm effort would also be signing up new projects that decided to use the work up for concerns they probably will not understand or expect. That probably isn't a good path to facilitate for new projects at this time. We will put a good faith effort to work well with others but keep in mind the project has limited bandwidth for such efforts. > Of course, I suspect it might be better if someone with that authority at Sun > would admit that the javax namespace is already in the wild and that there is > no problem with it being used within RXTX. > > Jim > > Trent Jarvi wrote: >> Hi Jim, >> >> I will not step into the javax.comm namespace without Sun's explicite >> permission. I fully understand the pain point you are trying to address. >> >> In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java >> Comm Linux) - which remains an integral part of rxtx. At the time it was a >> win for Sun and rxtx. >> >> The Sun commapi license is/was fairly clear that rxtx should not step into >> that namespace. It made sense as Sun was active in that space and rxtx may >> go into another namespace - it was an experiment in working with Sun. >> >> This may sound silly looking at something that happened almost 10 years >> ago. In a community of respect which Sun helped create, there is no >> question about what to do. I hope eventually Sun will step up and do a >> right thing too. >> >> I agree that this is hurting the API more than helping it. There are also >> questions about how to replace the API in the long term which includes HID >> support which isn't going well so far. >> >> Others that can't even look at Sun's javax.comm today and can look at >> Kaffe's contribution to classpathx can easily work around such >> restrictions. >> >> On Mon, 4 Aug 2008, Jim Redman wrote: >> >>> Has there been any work/would it be possible, to layer a javacomm >>> look-alike on top of the GNU code? >>> >>> The goal is not to move the javax code forward, but to emulate the >>> "legacy" javax packages for people who still need this. >>> >>> Jim >>> >>> Trent Jarvi wrote: >>>> It would be nice to work with Sun to resolve those longstanding issues. >>>> But it may not be practical unless the process goes as fast and painless >>>> as the grandfathering of commapi did. >>>> >>>> Another option may be the old kaffe extensions that moved to gnu >>>> classpathx. These don't have the native libraries but should provide >>>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>>> >>>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From sandeep at genevasoftech.com Wed Aug 6 00:03:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Wed, 06 Aug 2008 11:33:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: <48993EB8.30107@genevasoftech.com> Thank you Mr. Martin for your suggestion. The native file which is given in rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am getting the following error . Any suggestions to solve this issue. I am using Solaris SPARC 64 bit machine. ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) thrown while loading gnu.io.RXTXCommDriver Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(Unknown Source) at java.lang.ClassLoader.loadLibrary(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) at com.ReadFromModem.main(ReadFromModem.java:84) * * *Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid > that then > you're out of luck since I think that quite a bit of RXTX is not yet ready > for 64 bit. > > Cheers, > -- > *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > ------------------------------------------------------------------------ > *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On > Behalf Of *Sandeep Kumar K > *Sent:* Tuesday, August 05, 2008 7:19 PM > *To:* rxtx at qbang.org > *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so > for Solaris 9 > > Hi, > > Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 > bit machine. The librxtxSerial.so given in website is for Solaris 8. > > *-- > > Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/1e920343/attachment-0013.html From tjarvi at qbang.org Wed Aug 6 00:21:42 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 00:21:42 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <48993EB8.30107@genevasoftech.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> <48993EB8.30107@genevasoftech.com> Message-ID: Hi Sandeep You may be out of luck unless you can compile the 2.1 src in CVS (requires gnu make and gcc). But you could try the ToyBox(R)(TM) which is a collection of WiLdLy untested cross compiled 2.1-7 binaries covering everything from the ibm z series to embeded arm/ppc. To give an idea how poorly these are tested, I don't even know if z series machines have a serial port. ftp://www.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Solaris They should at least match the binary types. Actually, I think if you use the rxtx jar from CVS with that file, it should 'work' as the fix for 64 bits was in java not the native code. You could just cd rxtx*/src; javac *.java then jar -cf RXTXcomm.jar `find -name \*.class` to create the hybrid which will complain about version information a bit. On Wed, 6 Aug 2008, Sandeep Kumar K wrote: > Thank you Mr. Martin for your suggestion. The native file which is given in > rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am > getting the following error . > Any suggestions to solve this issue. > I am using Solaris SPARC 64 bit machine. > > ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar > java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 > (Possible cause: architecture word > width mismatch) thrown while loading gnu.io.RXTXCommDriver > Exception in thread "main" java.lang.UnsatisfiedLinkError: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF > class: ELFCLASS64 (Possible cause: > architecture word width mismatch) > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(Unknown Source) > at java.lang.ClassLoader.loadLibrary(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > at com.ReadFromModem.main(ReadFromModem.java:84) > > * > * > > *Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > > > Oberhuber, Martin wrote: >> Sandeep, >> shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse >> variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on >> Sol7 but I've successfully run it on Sol9 and Sol10. >> Or is your request really about a native 64bit variant? I'm afraid that >> then >> you're out of luck since I think that quite a bit of RXTX is not yet ready >> for 64 bit. >> Cheers, >> -- >> *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> ------------------------------------------------------------------------ >> *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On >> Behalf Of *Sandeep Kumar K >> *Sent:* Tuesday, August 05, 2008 7:19 PM >> *To:* rxtx at qbang.org >> *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so >> for Solaris 9 >> >> Hi, >> >> Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 >> bit machine. The librxtxSerial.so given in website is for Solaris 8. >> >> *-- >> Thanks & Regards >> >> Sandeep Kumar K >> Sr. Software Engineer >> Geneva Software Technologies >> Whitefield, Bangalore >> Mob : 9880193454* >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> From michael.erskine at ketech.com Wed Aug 6 01:39:28 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 6 Aug 2008 08:39:28 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Florian Manschwetus wrote: > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) Hi Florian, I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. Regards, Michael Erskine. From florianmanschwetus at gmx.de Wed Aug 6 02:53:16 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 06 Aug 2008 10:53:16 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Message-ID: <4899667C.6010706@gmx.de> Michael Erskine schrieb: > Florian Manschwetus wrote: >> Ok, sounds fine for the receiving problem. >> But why i have to wait after each byte when sending a command squence? >> (the for loop in send command) > > Hi Florian, > I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. > > Regards, > Michael Erskine. > correct with a terminal on the other end it works, my idea was that this basic baud has some influence. Could some one explain what it is for? Florian > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/c2b4fa84/attachment-0013.bin From rick_knight at rlknight.com Wed Aug 6 13:01:07 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:01:07 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F4F3.3020707@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > I have an application (Readerware) that uses RXTX with Javax to access the serial port. This used to work fine under previous Linux' and Java, but something has changed, I assume with Java itself , that is causing the application to fail with a link error. The application is not able to find librxtxSerialParallel.so. RXTX supplies librxtxSerial.so and librxtxParallel.so, but not librxtxSerialParallel.so. Where can I get librxtxSerialParallel.so, or do I need it? Is something else causing the lib to not be found? Thanks, Rick Knight From rick_knight at rlknight.com Wed Aug 6 13:17:55 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:17:55 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F8E3.5060400@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Thanks for the reply. The developer of the app I'm trying to use (Readerware) has sent me a copy of the comm.api and I've copied the library (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar into the proper places. When I try to run the application, I get this error... Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: /usr/lib/libSolarisSerialParallel.so: /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not little-endian (Possible cause: endianness mismatch) Caught java.lang.UnsatisfiedLinkError: com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I while loading driver com.sun.comm.SolarisDriver Is there a way around this error? Thanks again, Rick Knight From jlar310 at gmail.com Wed Aug 6 13:37:42 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 14:37:42 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899F8E3.5060400@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > The developer of the app I'm trying to use (Readerware) has sent me a > copy of the comm.api and I've copied the library > (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar > into the proper places. When I try to run the application, I get this > error... > > Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: > /usr/lib/libSolarisSerialParallel.so: > /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not > little-endian (Possible cause: endianness mismatch) > Caught java.lang.UnsatisfiedLinkError: > com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I > > while loading driver com.sun.comm.SolarisDriver > > Is there a way around this error? What host OS are you running? From your original post it looks like 32 bit Linux. The libSolarisSerialParallel.so file is for Sun Solaris and will vary depending on the underlying hardware architecture as well. Sorry for the double post Rick, but I failed to send this to the list the first time... -- Jeff From rick_knight at rlknight.com Wed Aug 6 13:44:29 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:44:29 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: <4899FF1D.9030504@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > > >> The developer of the app I'm trying to use (Readerware) has sent me a >> copy of the comm.api and I've copied the library >> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >> into the proper places. When I try to run the application, I get this >> error... >> >> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >> /usr/lib/libSolarisSerialParallel.so: >> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >> little-endian (Possible cause: endianness mismatch) >> Caught java.lang.UnsatisfiedLinkError: >> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >> >> while loading driver com.sun.comm.SolarisDriver >> >> Is there a way around this error? >> > > What host OS are you running? From your original post it looks like 32 > bit Linux. > > The libSolarisSerialParallel.so file is for Sun Solaris and will vary > depending on the underlying hardware architecture as well. > > I'm running Kubuntu Linux (debian based). It's 32 bit. Rick Knight From jlar310 at gmail.com Wed Aug 6 15:33:23 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 16:33:23 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > I don't think Sun did binary libraries for Linux in the 2.0 version. Can someone with more historical experience than I confirm that? I recently tried to port a Comm API application from Solaris sparc to Linux x86 and likewise could not get my hands on the binary libraries. I eventually just re-wrote the code to use the gnu namespace packages and rxtx 2.1. What I don't understand is why your application vendor does not provide everything you need to run their software. FYI: I have librxtxParallel.so and librxtxSerial.so installed at JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is /usr/java/default which is actually a softlink to /usr/java/jre1.6.0_05. -- Jeff From defiantlew at yahoo.com.au Wed Aug 6 16:29:33 2008 From: defiantlew at yahoo.com.au (Lew L) Date: Thu, 7 Aug 2008 08:29:33 +1000 Subject: [Rxtx] Sun's Comm API Documentation References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> Message-ID: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> As a matter of interest is the Sun Comm API documentation available somewhere? I have tried the Sun site but it seems to have been removed. Unless I have missed the documentation for RXTX? I javadocced the RXTX source but information (to me) is minimal. Somewhere I got the impression that the Sun Comm API docs is, or was, compatible with RXTX, what is the best docs to use in conjuntion with RXTX and where may the be available? Cheers Lew From rick_knight at rlknight.com Wed Aug 6 17:18:33 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:18:33 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A3149.4050306@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff I'm not sure if I posted this here or not, but when I try to build RXTX from source I get this install error... make all-am make[1]: Entering directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' make[1]: Nothing to be done for `all-am'. make[1]: Leaving directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 Can you tell me how to get past this error and get RXTX built and installed? Thanks, Rick From bboyes at systronix.com Wed Aug 6 17:40:12 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Wed, 06 Aug 2008 17:40:12 -0600 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: At 16:29 08/06/2008, Lew L wrote: >As a matter of interest is the Sun Comm API documentation available >somewhere? I have tried the Sun site but it seems to have been removed. It's in the file we have posted, link in prev email (sorry, in a huge hurry right now). Javadocs definitely there. >Unless I have missed the documentation for RXTX? I javadocced the RXTX >source but information (to me) is minimal. >Somewhere I got the impression that the Sun Comm API docs is, or was, >compatible with RXTX, what is the best docs to use in conjuntion with RXTX >and where may the be available? Yeah, this is one of my concerns/beefs. There is little documentation for RXTX and it isn't just the same as javaxcomm. I would be willing to help out writing docs for RXTX! Yes really... esp if we can fix the Bluetooth issues. best regards Bruce >Cheers >Lew > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx ------- WWW.SYSTRONIX.COM ---------- Real embedded Java and much more +1-801-534-1017 Salt Lake City, USA From rick_knight at rlknight.com Wed Aug 6 17:54:08 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:54:08 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A39A0.2090309@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff, I would like for my vendor to switch to rxtx 2.1. It would make things much easier for me. I'm not sure why he's still using the javax compatible code. He's a small operation. Re-writing the code to use gnu namespace sounds like a major overhaul. Was it? Thanks, Rick From tjarvi at qbang.org Wed Aug 6 21:35:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:35:12 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: >> >>> Jeff wrote: >>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>>> >>>> >>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things > much easier for me. I'm not sure why he's still using the javax > compatible code. He's a small operation. Re-writing the code to use gnu > namespace sounds like a major overhaul. Was it? > Hi Jeff, The changes are fairly mechanical. Imports need to change and any explicite use of the namespace needs to change such as catching an exception. The following script was made for maintaining rxtx 2.0 but can apply to other needs. It is in the contrib dir with rxtx source. #!/bin/sh # Don't use! :) # # Sat, 03 May 2003 16:45:08 Modifications from J?rg Weule # Create a ed-cmd for the change of one pattern # case $1 in gnu) X=g/javax_comm/s+javax_comm+gnu_io+g ;; javax) X=g/gnu_io/s+gnu_io+javax_comm+g ;; *) echo;echo;echo From the top rxtx directory run;echo;echo -e \\t./ChangePackage.sh gnu;echo -e \\t\\tor;echo -e \\t./ChangePackage.sh javax;echo;echo; exit 0 ;; esac # # ed will be used to keep the owner and mode of the files unchanged. # We have run the ed-script for the characters '.' '/' as well. # "tr _ $D" do the change. # find . -type f -a -print | grep -v $0 | (while read F ; do ( echo $X; echo $X| tr _ /; echo $X| tr _ .; echo w; echo q ) | ed $F 2>&1 >/dev/null done ) # # Now we do little changes at the Makefiles. Hope that all we need. # find . -name Makefile\* -a -print | (while read F ; do cat < References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: On Thu, 7 Aug 2008, Lew L wrote: > As a matter of interest is the Sun Comm API documentation available > somewhere? I have tried the Sun site but it seems to have been removed. > > Unless I have missed the documentation for RXTX? I javadocced the RXTX > source but information (to me) is minimal. > Somewhere I got the impression that the Sun Comm API docs is, or was, > compatible with RXTX, what is the best docs to use in conjuntion with RXTX > and where may the be available? > Hi Lew, The documentation on Sun's website is accurate. The changes that are problematic in 3.0 are on the backside which rxtx used to plug into. http://java.sun.com/products/javacomm/reference/api/index.html CommPortIdentifier may have some minor differences (judging by the authors notes). -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Aug 6 21:46:08 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:46:08 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > If javax.comm.properties is properly installed and you are using a 2.0 version of Sun's commapi with rxtx 2.0, you should not see the library attempt to load libSolarisSerialParallel.so. Sun CommAPI 3.0 will not work with any version of rxtx as it is hard coded to use the shared library. See the INSTALL file with rxtx-2.0 source for more help with the properties file. -- Trent Jarvi tjarvi at qbang.org From jlar310 at gmail.com Thu Aug 7 06:32:06 2008 From: jlar310 at gmail.com (Jeff) Date: Thu, 7 Aug 2008 07:32:06 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > Jeff wrote: >> >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >> wrote: >> >>> >>> Jeff wrote: >>> >>>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>> wrote: >>>> >>>> >>>> >>>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things much > easier for me. I'm not sure why he's still using the javax compatible code. > He's a small operation. Re-writing the code to use gnu namespace sounds like > a major overhaul. Was it? I found it quite easy. In fact, in order to accommodate the transition, I actually separated all of the code that deals directly with the Comm API or RXTX into a helper class. The helper class was then coded to use reflection to determine which library was available and then instantiate the necessary objects. No direct imports of either library are used. The main application just needs to get it's hands on the IO streams and need not deal directly with the libraries. Other programs may not be so simple... But this doesn't really help you unless your vendor forks over the source code... -- Jeff From rick_knight at rlknight.com Thu Aug 7 09:47:12 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Thu, 07 Aug 2008 08:47:12 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: <489B1900.10108@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >>> wrote: >>> >>> >>>> Jeff wrote: >>>> >>>> >>>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>>> copy of the comm.api and I've copied the library >>>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>>> into the proper places. When I try to run the application, I get this >>>>>> error... >>>>>> >>>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>>> /usr/lib/libSolarisSerialParallel.so: >>>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>>> little-endian (Possible cause: endianness mismatch) >>>>>> Caught java.lang.UnsatisfiedLinkError: >>>>>> >>>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>>> >>>>>> while loading driver com.sun.comm.SolarisDriver >>>>>> >>>>>> Is there a way around this error? >>>>>> >>>>>> >>>>>> >>>>> What host OS are you running? From your original post it looks like 32 >>>>> bit Linux. >>>>> >>>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>>> depending on the underlying hardware architecture as well. >>>>> >>>>> >>>>> >>>>> >>>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>>> >>>> >>>> >>> I don't think Sun did binary libraries for Linux in the 2.0 version. >>> Can someone with more historical experience than I confirm that? >>> >>> I recently tried to port a Comm API application from Solaris sparc to >>> Linux x86 and likewise could not get my hands on the binary libraries. >>> I eventually just re-wrote the code to use the gnu namespace packages >>> and rxtx 2.1. >>> >>> What I don't understand is why your application vendor does not >>> provide everything you need to run their software. >>> >>> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >>> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >>> /usr/java/default which is actually a softlink to >>> /usr/java/jre1.6.0_05. >>> >>> >>> >> Jeff, >> >> I would like for my vendor to switch to rxtx 2.1. It would make things much >> easier for me. I'm not sure why he's still using the javax compatible code. >> He's a small operation. Re-writing the code to use gnu namespace sounds like >> a major overhaul. Was it? >> > > I found it quite easy. In fact, in order to accommodate the > transition, I actually separated all of the code that deals directly > with the Comm API or RXTX into a helper class. The helper class was > then coded to use reflection to determine which library was available > and then instantiate the necessary objects. No direct imports of > either library are used. The main application just needs to get it's > hands on the IO streams and need not deal directly with the libraries. > Other programs may not be so simple... > > But this doesn't really help you unless your vendor forks over the > source code... > > Jeff, This may not help me directly, but I'm going to forward this thread to the vendor. I think he'll be open to making things work. Thanks again, Rick Knight From agusmunioz at gmail.com Thu Aug 7 16:39:51 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Thu, 7 Aug 2008 19:39:51 -0300 Subject: [Rxtx] How to send ack? Message-ID: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Hi, I'm still learning about serial communication and I have some doubts. I've got this question about how to do the following thing in rxtx. I have this hardware that connect to a PC using a serial port. These hardware receives data from a telephone line, proccess it, and then send it forward to the serial port. I've used a program named wincomm that shows what information is send it through the serial port and I have the nex behaviour: The hardware has a buffer where all data is stored, that cannot be sent it through the seria port. The program reads the first data send it by the hardware, and keep reading the same data always. There is a button in the application that says enable Ack, and when I click, then the hardware start to send all the stored information, and all the information is shown. I write a class, using rxtx that reads the serial port, and the same thing happens, it remains reading the same (first) data all the time. And I thing something like the enable Ack I'm missing. How can I do this enable Ack from my java code using rxtx? Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080807/e0a0f9a1/attachment-0011.html From ajmas at sympatico.ca Thu Aug 7 18:26:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 7 Aug 2008 20:26:41 -0400 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: <4BF42297-81E2-4BB8-A89F-1D43588379AE@sympatico.ca> On 6-Aug-08, at 19:40 , Bruce Boyes wrote: >> Unless I have missed the documentation for RXTX? I javadocced the >> RXTX >> source but information (to me) is minimal. >> Somewhere I got the impression that the Sun Comm API docs is, or was, >> compatible with RXTX, what is the best docs to use in conjuntion >> with RXTX >> and where may the be available? > > Yeah, this is one of my concerns/beefs. There is little documentation > for RXTX and it isn't just the same as javaxcomm. > > I would be willing to help out writing docs for RXTX! Yes really... > esp if we can fix the Bluetooth issues. If you want to contribute documentation then the best place to do that is the wiki. If there is anything missing or that could be improved on then please do so. If there are any points that you would like to see improved, for which you don't have the knowledge then ask on the mailing list for a volunteer. Andre From florianmanschwetus at gmx.de Fri Aug 8 03:04:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Fri, 08 Aug 2008 11:04:14 +0200 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Message-ID: <489C0C0E.2020401@gmx.de> Agustin Mu?oz schrieb: > Hi, I'm still learning about serial communication and I have some > doubts. I've got this question about how to do the following thing in rxtx. > I have this hardware that connect to a PC using a serial port. These > hardware receives data from a telephone line, proccess it, and then send > it forward to the serial port. I've used a program named wincomm that > shows what information is send it through the serial port and I have the > nex behaviour: > > The hardware has a buffer where all data is stored, that cannot be sent > it through the seria port. > The program reads the first data send it by the hardware, and keep > reading the same data always. > There is a button in the application that says enable Ack, and when I > click, then the hardware start to send all the stored information, and > all the information is shown. > > I write a class, using rxtx that reads the serial port, and the same > thing happens, it remains reading the same (first) data all the time. > And I thing something like the enable Ack I'm missing. > How can I do this enable Ack from my java code using rxtx? Afaik, a look at man ascii reveals: Okt Dez Hex Char 006 6 06 ACK So, i hope this will do the job: send(6); florian > > Thanks in advance > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/5b4965f8/attachment-0011.bin From agusmunioz at gmail.com Fri Aug 8 16:31:00 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 19:31:00 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <489C0C0E.2020401@gmx.de> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> Message-ID: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Hi Florian, thanks for the answer. By send(6) you mean to get the port OutputStream and write a 6? I try that but it didn't work. Any suggestion? Thanks On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < florianmanschwetus at gmx.de> wrote: > Agustin Mu?oz schrieb: > > Hi, I'm still learning about serial communication and I have some doubts. >> I've got this question about how to do the following thing in rxtx. >> I have this hardware that connect to a PC using a serial port. These >> hardware receives data from a telephone line, proccess it, and then send it >> forward to the serial port. I've used a program named wincomm that shows >> what information is send it through the serial port and I have the nex >> behaviour: >> >> The hardware has a buffer where all data is stored, that cannot be sent >> it through the seria port. >> The program reads the first data send it by the hardware, and keep reading >> the same data always. >> There is a button in the application that says enable Ack, and when I >> click, then the hardware start to send all the stored information, and all >> the information is shown. >> >> I write a class, using rxtx that reads the serial port, and the same thing >> happens, it remains reading the same (first) data all the time. And I thing >> something like the enable Ack I'm missing. >> How can I do this enable Ack from my java code using rxtx? >> > Afaik, a look at man ascii reveals: > Okt Dez Hex Char > 006 6 06 ACK > So, i hope this will do the job: > send(6); > > florian > >> >> Thanks in advance >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/7f3fba42/attachment-0010.html From agusmunioz at gmail.com Fri Aug 8 18:39:27 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 21:39:27 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Message-ID: <988288430808081739x7f9e7889id82591d5a9e2b4f6@mail.gmail.com> Ok, Florian, it works!! my problem was that I've been sending, through the OutputStream, the bytes of 6 as a string: out.write("6".getBytes()); but then I realized that you can write an int on an OuptuStream, so I tried that and It works: out.write(6); Thank you for the guidance!! On Fri, Aug 8, 2008 at 7:31 PM, Agustin Mu?oz wrote: > Hi Florian, thanks for the answer. By send(6) you mean to get the port > OutputStream and write a 6? > > I try that but it didn't work. > > Any suggestion? > > Thanks > > > On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < > florianmanschwetus at gmx.de> wrote: > >> Agustin Mu?oz schrieb: >> >> Hi, I'm still learning about serial communication and I have some doubts. >>> I've got this question about how to do the following thing in rxtx. >>> I have this hardware that connect to a PC using a serial port. These >>> hardware receives data from a telephone line, proccess it, and then send it >>> forward to the serial port. I've used a program named wincomm that shows >>> what information is send it through the serial port and I have the nex >>> behaviour: >>> >>> The hardware has a buffer where all data is stored, that cannot be sent >>> it through the seria port. >>> The program reads the first data send it by the hardware, and keep >>> reading the same data always. >>> There is a button in the application that says enable Ack, and when I >>> click, then the hardware start to send all the stored information, and all >>> the information is shown. >>> >>> I write a class, using rxtx that reads the serial port, and the same >>> thing happens, it remains reading the same (first) data all the time. And I >>> thing something like the enable Ack I'm missing. >>> How can I do this enable Ack from my java code using rxtx? >>> >> Afaik, a look at man ascii reveals: >> Okt Dez Hex Char >> 006 6 06 ACK >> So, i hope this will do the job: >> send(6); >> >> florian >> >>> >>> Thanks in advance >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/b918ab3d/attachment-0010.html From florianmanschwetus at gmx.de Sat Aug 9 00:45:43 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Sat, 09 Aug 2008 08:45:43 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4899667C.6010706@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> Message-ID: <489D3D17.9090209@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >> Florian Manschwetus wrote: >>> Ok, sounds fine for the receiving problem. >>> But why i have to wait after each byte when sending a command squence? >>> (the for loop in send command) >> >> Hi Florian, >> I'd imagine you probably don't! You could send all bytes in one go and >> RXTX would send them. The problem is most probably the other end: >> perhaps it has a really small buffer, some non-standard UART, or a >> crazy timing issue. If you attach a terminal to your output and send >> all the bytes of a command in one go they should appear no problem. >> >> Regards, >> Michael Erskine. >> > correct with a terminal on the other end it works, my idea was that this > basic baud has some influence. Could some one explain what it is for? > > Florian To make it more clear, my problem is that i can't use: outputStream.write(byte[]); => Beamer doesn't understand the sequence. (mostly no answer when he answers then *001) when i use this construct instead: for (int i = 0; i < command.length; i++) { this.outputStream.write(command[i]); try { Thread.sleep(25); } catch (InterruptedException e) { // TODO Auto-generated catch block e.printStackTrace(); } } it works nearly reliable. So what could it be? This Basic Baud is what exactly? Florian -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080809/692304ee/attachment-0010.bin From tjarvi at qbang.org Sat Aug 9 16:37:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Aug 2008 16:37:19 -0600 (MDT) Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489D3D17.9090209@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> <489D3D17.9090209@gmx.de> Message-ID: On Sat, 9 Aug 2008, Florian Manschwetus wrote: > Florian Manschwetus schrieb: >> Michael Erskine schrieb: >>> Florian Manschwetus wrote: >>>> Ok, sounds fine for the receiving problem. >>>> But why i have to wait after each byte when sending a command squence? >>>> (the for loop in send command) >>> >>> Hi Florian, >>> I'd imagine you probably don't! You could send all bytes in one go and >>> RXTX would send them. The problem is most probably the other end: perhaps >>> it has a really small buffer, some non-standard UART, or a crazy timing >>> issue. If you attach a terminal to your output and send all the bytes of a >>> command in one go they should appear no problem. >>> >>> Regards, >>> Michael Erskine. >>> >> correct with a terminal on the other end it works, my idea was that this >> basic baud has some influence. Could some one explain what it is for? >> >> Florian > To make it more clear, > my problem is that i can't use: > outputStream.write(byte[]); > => Beamer doesn't understand the sequence. (mostly no answer when he answers > then *001) > > when i use this construct instead: > > for (int i = 0; i < command.length; i++) { > this.outputStream.write(command[i]); > try { > Thread.sleep(25); > } catch (InterruptedException e) { > // TODO Auto-generated catch block > e.printStackTrace(); > } > } > > it works nearly reliable. > > So what could it be? This Basic Baud is what exactly? > I suspect you are using the 'moon protocol' and don't know it. RXTX enables this by default. The buffer on the other end is first in first out while reading. If the buffer is full, the bits are hand carried to the moon and burried. Then if the other side reads a couple bytes, two more bytes go into the buffer followed by more moon protocol. The resulting array of bytes the other side reads may appear to be scrambled until you go to the moon, get the bits and insert them in the right place. Flow control can prevent the default moon protocol and throttles the communiation by almost writing a byte at a time as need be. Hardware flow control is preferable but software flow control should also work. Read and write can appear to hang if the other side is not connected. This is why we don't enable them all the time. If you can't use flow control, you have to take care with the moon protocol and give the other side time to read. That is what your slower version of write is doing. -- Trent Jarvi tjarvi at qbang.org From rxtx at allenjb.me.uk Mon Aug 11 08:06:36 2008 From: rxtx at allenjb.me.uk (AllenJB) Date: Mon, 11 Aug 2008 15:06:36 +0100 Subject: [Rxtx] Disabling EV_RXFLAG Message-ID: <48A0476C.2090800@allenjb.me.uk> Hi all, I'm working with a device which does not use an EvtChar and need to disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an event mask of FD 01 00 00. The reference software I have uses FB 00 00 00. With the rxtx mask I get framing errors which I believe are caused when the EvtChar is received. Is there currently a way with rxtx (I've using rxtx from Java) to disable EV_RXFLAG? If not from Java, where would I start if I wanted to turn the EV_RXFLAG option off in the C code? I've had a grep of the rxtx source code, but I can't see where EV_RXFLAG is being set. Thanks in advance, AllenJB From tjarvi at qbang.org Mon Aug 11 14:17:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Aug 2008 14:17:27 -0600 (MDT) Subject: [Rxtx] Disabling EV_RXFLAG In-Reply-To: <48A0476C.2090800@allenjb.me.uk> References: <48A0476C.2090800@allenjb.me.uk> Message-ID: On Mon, 11 Aug 2008, AllenJB wrote: > Hi all, > > I'm working with a device which does not use an EvtChar and need to > disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an > event mask of FD 01 00 00. The reference software I have uses FB 00 00 > 00. With the rxtx mask I get framing errors which I believe are caused > when the EvtChar is received. > > Is there currently a way with rxtx (I've using rxtx from Java) to > disable EV_RXFLAG? > > If not from Java, where would I start if I wanted to turn the EV_RXFLAG > option off in the C code? I've had a grep of the rxtx source code, but I > can't see where EV_RXFLAG is being set. > > Thanks in advance, > > AllenJB Hi Allen, I'd look at termios.c::tcsetattr() and termios.c::FillDCB() -- Trent Jarvi tjarvi at qbang.org From superdadusa at gmail.com Tue Aug 12 13:57:32 2008 From: superdadusa at gmail.com (John Choi) Date: Tue, 12 Aug 2008 13:57:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. Message-ID: Hi all, Just let you all know I just start to learn Java. I have download the serial comm package and the source code from open source communities.. I was able to verify with the given message string via serial monitor. when the given message string sends to the serial port then the character return added to the end of string by default if I use "Hello World" however if I changed to something else other than "Hello, World" there is no character return add to the end of string. I thing the library download from rxtx.org has implemented for the special strings. I can do like "login\n" in the string message to make character return but I don't want to add this individual custom character for each command return in every static message string I send, Can any who have done this might help me? Basically, something like this,, Write and add function to the program write a command, Reads the respond from a serial device.. Function handles multiple messages, Write: "com open" Read: Welcome to my world" expected Write: "admin" Read: Password?, expected Write: "admin" Read: you are successfully login terminal, expected. And I need to add a separate function handler handles a character return add to the each command above. If anyone can help this I can do the reset? Thank you in advance, John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0006.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SerialIO.java Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0006.pl From Steffen.DETTMER at ingenico.com Wed Aug 13 02:16:38 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 13 Aug 2008 10:16:38 +0200 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: References: Message-ID: <20080813081638.GA25412@elberon.bln.de.ingenico.com> * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > I can do like "login\n" in the string message to make character > return but I don't want to add this individual custom character > for each command return in every static message string I send, and why not?! > Can any who have done this might help me? what's about with writing a small wrapper function adding the carriage return? However, this would be slow, because either you call write two times (very bad) or the string needs to be copied, \n appended and written (since you are using Java Performance probably isn't so critical). Personally I would write `"login\n"' and `username + "\n"' etc., because since it is part of the command it should be part of the command definition string. > Basically, something like this,, Write and add function to the program write > a command, Reads the respond from a serial device.. correctly reading a `line' is more difficult. If you cannot make assumptions about timeouts and/or you need to have low delay, you need to read byte wise. If you need to save CPU resources you might need to add some buffering layer that you can read byte-wise but that is reading blockwise with some small timeout (lets say for serial lines something around byte transmission time times three or so). > /* > * To change this template, choose Tools | Templates > * and open the template in the editor. > */ :) > package joliba; > > /** > * > * @author root > */ :) > // derived from SUN's examples in the javax.comm package > import java.io.*; > import java.util.*; > //import javax.comm.*; // for SUN's serial/parallel port libraries > import gnu.io.*; // for rxtxSerial library > > public class SerialIO implements Runnable, SerialPortEventListener { > static CommPortIdentifier portId; > static CommPortIdentifier saveportId; > static Enumeration portList; > InputStream inputStream; > SerialPort serialPort; > Thread readThread; You need a thread for your synchronous RPC-style protocol? > static String messageString = "Hello, world!"; > static OutputStream outputStream; > static boolean outputBufferEmptyFlag = false; > > public static void main(String[] args) { > boolean portFound = false; > String defaultPort; > > // determine the name of the serial port on several operating systems > String osname = System.getProperty("os.name","").toLowerCase(); > if ( osname.startsWith("windows") ) { > // windows > defaultPort = "COM1"; > } else if (osname.startsWith("linux")) { > // linux > defaultPort = "/dev/ttyS0"; > } else if ( osname.startsWith("mac") ) { > // mac > defaultPort = "????"; > } else { > System.out.println("Sorry, your operating system is not supported"); > return; > } Is such a construction recommended? Isn't there some abstraction (like COM1 working on any platform)? [...] > try { > // activate the OUTPUT_BUFFER_EMPTY notifier > serialPort.notifyOnOutputEmpty(true); > } catch (Exception e) { > System.out.println("Error setting event notification"); > System.out.println(e.toString()); > System.exit(-1); > } I doubt that -1 is defined, probably some 127 or so would be the result, maybe better simply `throw e'? > public void writetoport() { > System.out.println("Writing \""+messageString+"\" to "+serialPort.getName()); > try { > // write string to serial port > outputStream.write(messageString.getBytes()); > } catch (IOException e) {} > } maybe something like /** * Writes the given output string and an additional carriage * return to the current outputStream. */ public void writeStringToPort( /** The output string (without CR). */ String output ) throws IOException { String outputLine = output + "\n"; outputStream.write(outputLine.getBytes()); } ? > > public SerialIO() { > // initalize serial port > try { > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > } catch (PortInUseException e) {} if the port is in use, you continue? Wonder that this works in Java, I would assume serialPort beeing uninitialized which AFAIK is an error in Java. > try { > inputStream = serialPort.getInputStream(); > } catch (IOException e) {} > > try { > serialPort.addEventListener(this); > } catch (TooManyListenersException e) {} > > // activate the DATA_AVAILABLE notifier > serialPort.notifyOnDataAvailable(true); > > try { > // set port parameters > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > } catch (UnsupportedCommOperationException e) {} > > // start the read thread > readThread = new Thread(this); > readThread.start(); > > } I think in all those exception cases you can abort, because it is unlikely that ignoring those errors allow a successful continuation, so in this case maybe it would be better to add a throw clause to the method. > public void run() { > // first thing in the thread, we initialize the write operation > initwritetoport(); > try { > while (true) { > // write string to port, the serialEvent will read it > writetoport(); > Thread.sleep(1000); > } > } catch (InterruptedException e) {} > } Does this make sense? Your `SimpleReadApp' writes one and the same string each second? > public void serialEvent(SerialPortEvent event) { > switch (event.getEventType()) { > case SerialPortEvent.BI: > case SerialPortEvent.OE: > case SerialPortEvent.FE: > case SerialPortEvent.PE: > case SerialPortEvent.CD: > case SerialPortEvent.CTS: > case SerialPortEvent.DSR: > case SerialPortEvent.RI: > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > break; > case SerialPortEvent.DATA_AVAILABLE: > // we get here if data has been received > byte[] readBuffer = new byte[20]; > try { > // read data > while (inputStream.available() > 0) { > int numBytes = inputStream.read(readBuffer); > } > // print data > String result = new String(readBuffer); > System.out.println("Read: "+result); > } catch (IOException e) {} I doubt that this is correct. I would assume you will get a 20 bytes result always, if more bytes would be available they would be printed in a second line but if less bytes are read I'd assume that the buffer/result contains zero bytes from implicite readBuffer contents initialisation (zero is no string terminator in Java AFAIK). > break; > } > } > } oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From florianmanschwetus at gmx.de Wed Aug 13 06:09:31 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 13 Aug 2008 14:09:31 +0200 Subject: [Rxtx] someone has seen such errors? Message-ID: <48A2CEFB.90007@gmx.de> I mean my communication mostly works, but it is far from perfect could this be the reason? Florian Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/949b9947/attachment-0006.bin From superdadusa at gmail.com Wed Aug 13 08:40:32 2008 From: superdadusa at gmail.com (John Choi) Date: Wed, 13 Aug 2008 08:40:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: <20080813081638.GA25412@elberon.bln.de.ingenico.com> References: <20080813081638.GA25412@elberon.bln.de.ingenico.com> Message-ID: Thank you so much Steffen and I will try that suggestion. John On 8/13/08, Steffen DETTMER wrote: > > * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > > I can do like "login\n" in the string message to make character > > return but I don't want to add this individual custom character > > for each command return in every static message string I send, > > and why not?! > > > Can any who have done this might help me? > > what's about with writing a small wrapper function adding the > carriage return? > However, this would be slow, because either you call write two > times (very bad) or the string needs to be copied, \n appended > and written (since you are using Java Performance probably isn't > so critical). > > Personally I would write `"login\n"' and `username + "\n"' etc., > because since it is part of the command it should be part of the > command definition string. > > > Basically, something like this,, Write and add function to the program > write > > a command, Reads the respond from a serial device.. > > correctly reading a `line' is more difficult. If you cannot make > assumptions about timeouts and/or you need to have low delay, you > need to read byte wise. If you need to save CPU resources you > might need to add some buffering layer that you can read > byte-wise but that is reading blockwise with some small timeout > (lets say for serial lines something around byte transmission > time times three or so). > > > /* > > * To change this template, choose Tools | Templates > > * and open the template in the editor. > > */ > > :) > > > package joliba; > > > > /** > > * > > * @author root > > */ > > :) > > > // derived from SUN's examples in the javax.comm package > > import java.io.*; > > import java.util.*; > > //import javax.comm.*; // for SUN's serial/parallel port libraries > > import gnu.io.*; // for rxtxSerial library > > > > public class SerialIO implements Runnable, SerialPortEventListener { > > static CommPortIdentifier portId; > > static CommPortIdentifier saveportId; > > static Enumeration portList; > > InputStream inputStream; > > SerialPort serialPort; > > Thread readThread; > > You need a thread for your synchronous RPC-style protocol? > > > static String messageString = "Hello, world!"; > > static OutputStream outputStream; > > static boolean outputBufferEmptyFlag = false; > > > > public static void main(String[] args) { > > boolean portFound = false; > > String defaultPort; > > > > // determine the name of the serial port on several operating > systems > > String osname = System.getProperty("os.name","").toLowerCase(); > > if ( osname.startsWith("windows") ) { > > // windows > > defaultPort = "COM1"; > > } else if (osname.startsWith("linux")) { > > // linux > > defaultPort = "/dev/ttyS0"; > > } else if ( osname.startsWith("mac") ) { > > // mac > > defaultPort = "????"; > > } else { > > System.out.println("Sorry, your operating system is not > supported"); > > return; > > } > > Is such a construction recommended? Isn't there some abstraction > (like COM1 working on any platform)? > > [...] > > try { > > // activate the OUTPUT_BUFFER_EMPTY notifier > > serialPort.notifyOnOutputEmpty(true); > > } catch (Exception e) { > > System.out.println("Error setting event notification"); > > System.out.println(e.toString()); > > System.exit(-1); > > } > > I doubt that -1 is defined, probably some 127 or so would be the > result, maybe better simply `throw e'? > > > public void writetoport() { > > System.out.println("Writing \""+messageString+"\" to > "+serialPort.getName()); > > try { > > // write string to serial port > > outputStream.write(messageString.getBytes()); > > } catch (IOException e) {} > > } > > maybe something like > > /** > * Writes the given output string and an additional carriage > * return to the current outputStream. > */ > public void > writeStringToPort( > /** The output string (without CR). */ > String output > ) throws IOException > { > String outputLine = output + "\n"; > outputStream.write(outputLine.getBytes()); > } > > ? > > > > > public SerialIO() { > > // initalize serial port > > try { > > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > > } catch (PortInUseException e) {} > > if the port is in use, you continue? Wonder that this works in > Java, I would assume serialPort beeing uninitialized which AFAIK > is an error in Java. > > > try { > > inputStream = serialPort.getInputStream(); > > } catch (IOException e) {} > > > > try { > > serialPort.addEventListener(this); > > } catch (TooManyListenersException e) {} > > > > // activate the DATA_AVAILABLE notifier > > serialPort.notifyOnDataAvailable(true); > > > > try { > > // set port parameters > > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > } catch (UnsupportedCommOperationException e) {} > > > > // start the read thread > > readThread = new Thread(this); > > readThread.start(); > > > > } > > I think in all those exception cases you can abort, because it is > unlikely that ignoring those errors allow a successful > continuation, so in this case maybe it would be better to add a > throw clause to the method. > > > public void run() { > > // first thing in the thread, we initialize the write operation > > initwritetoport(); > > try { > > while (true) { > > // write string to port, the serialEvent will read it > > writetoport(); > > Thread.sleep(1000); > > } > > } catch (InterruptedException e) {} > > } > > Does this make sense? Your `SimpleReadApp' writes one and the > same string each second? > > > public void serialEvent(SerialPortEvent event) { > > switch (event.getEventType()) { > > case SerialPortEvent.BI: > > case SerialPortEvent.OE: > > case SerialPortEvent.FE: > > case SerialPortEvent.PE: > > case SerialPortEvent.CD: > > case SerialPortEvent.CTS: > > case SerialPortEvent.DSR: > > case SerialPortEvent.RI: > > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > > break; > > case SerialPortEvent.DATA_AVAILABLE: > > // we get here if data has been received > > byte[] readBuffer = new byte[20]; > > try { > > // read data > > while (inputStream.available() > 0) { > > int numBytes = inputStream.read(readBuffer); > > } > > // print data > > String result = new String(readBuffer); > > System.out.println("Read: "+result); > > } catch (IOException e) {} > > I doubt that this is correct. I would assume you will get a 20 > bytes result always, if more bytes would be available they would > be printed in a second line but if less bytes are read I'd assume > that the buffer/result contains zero bytes from implicite > readBuffer contents initialisation (zero is no string terminator > in Java AFAIK). > > > break; > > } > > } > > } > > oki, > > Steffen > > About Ingenico Throughout the world businesses rely on Ingenico for secure > and expedient electronic transaction acceptance. Ingenico products leverage > proven technology, established standards and unparalleled ergonomics to > provide optimal reliability, versatility and usability. This comprehensive > range of products is complemented by a global array of services and > partnerships, enabling businesses in a number of vertical sectors to accept > transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged > information. If you are not the addressee or authorized to receive this for > the addressee, you must not use, copy, disclose or take any action based on > this message or any information herein. If you have received this message in > error, please advise the sender immediately by reply e-mail and delete this > message. Thank you for your cooperation. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/73c4135c/attachment-0005.html From ajmas at sympatico.ca Sat Aug 16 07:15:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 09:15:41 -0400 Subject: [Rxtx] someone has seen such errors? In-Reply-To: <48A2CEFB.90007@gmx.de> References: <48A2CEFB.90007@gmx.de> Message-ID: <43B5E8DA-1D93-4D90-809B-AAF35FF724C5@sympatico.ca> On 13-Aug-08, at 08:09 , Florian Manschwetus wrote: > I mean my communication mostly works, but it is far from perfect > could this be the reason? > > Florian > > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control Judging by the error messages this looks related to the driver you are using. Do a search for the following string with you favourite search engine, it should turn up a few hits: ftdi_set_termios FAILED to set databits/stopbits/parity Andre From ajmas at sympatico.ca Sat Aug 16 19:12:04 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 21:12:04 -0400 Subject: [Rxtx] Using SerialPortEvent? Message-ID: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Hi, Could someone tell me how I should be using the SerialPortEvent? Am I meant to be waiting for data and then simply reading from the inputstream? If this is the case why no just block on an inputstream read? Andr? From tjarvi at qbang.org Sat Aug 16 19:41:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 16 Aug 2008 19:41:13 -0600 (MDT) Subject: [Rxtx] Using SerialPortEvent? In-Reply-To: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> References: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Message-ID: On Sat, 16 Aug 2008, Andre-John Mas wrote: > Hi, > > Could someone tell me how I should be using the SerialPortEvent? Am I > meant to be waiting for data and then simply reading from the > inputstream? If this is the case why no just block on an inputstream > read? > Polling for data is fine also. It really depends upon what you are trying to do. For instance, if you require x bytes before reading, you can start polling after data is available. If you read on the same thread as your GUI and are waiting for data in a read, the results may be less than desirable. Java programming is 'usually' event driven rather than polling based. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sat Aug 16 20:10:39 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 22:10:39 -0400 Subject: [Rxtx] Using SerialPortEvent? In-Reply-To: References: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Message-ID: <3E495D4C-BB28-4845-A6AB-984C9A826BDF@sympatico.ca> On 16-Aug-08, at 21:41 , Trent Jarvi wrote: > On Sat, 16 Aug 2008, Andre-John Mas wrote: > >> Hi, >> >> Could someone tell me how I should be using the SerialPortEvent? Am I >> meant to be waiting for data and then simply reading from the >> inputstream? If this is the case why no just block on an inputstream >> read? >> > > Polling for data is fine also. It really depends upon what you are > trying to do. For instance, if you require x bytes before reading, > you can start polling after data is available. If you read on the > same thread as your GUI and are waiting for data in a read, the > results may be less than desirable. > > Java programming is 'usually' event driven rather than polling based. Sounds good. I thought I would use this opportunity to provide a event based version of the TwoWaySerialComm example. Could you just validate it before I add it to the Wiki: package ajmas74.experimental; import gnu.io.CommPort; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; import gnu.io.SerialPortEvent; import gnu.io.SerialPortEventListener; import java.io.IOException; import java.io.InputStream; import java.io.OutputStream; /** * This version of the TwoWaySerialComm example makes use of the * SerialPortEventListener to avoid polling. * * @author ajmas * */ public class TwoWaySerialComm { public TwoWaySerialComm() { super(); } void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { CommPort commPort = portIdentifier.open(this.getClass().getName(),2000); if ( commPort instanceof SerialPort ) { SerialPort serialPort = (SerialPort) commPort; serialPort .setSerialPortParams (57600 ,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); (new Thread(new SerialWriter(out))).start(); serialPort.addEventListener(new SerialReader(in)); } else { System.out.println("Error: Only serial ports are handled by this example."); } } } /** * Handles the input coming from the serial port. A new line character * is treated as the end of a block in this example. */ public static class SerialReader implements SerialPortEventListener { private InputStream in; private byte[] buffer = new byte[1024]; public SerialReader ( InputStream in ) { this.in = in; } public void serialEvent(SerialPortEvent arg0) { int data; try { int len = 0; while ( ( data = in.read()) > -1 ) { if ( data != '\n' ) { break; } buffer[len++] = (byte) data; } System.out.print(new String(buffer,0,len)); } catch ( IOException e ) { e.printStackTrace(); System.exit(-1); } } } /** */ public static class SerialWriter implements Runnable { OutputStream out; public SerialWriter ( OutputStream out ) { this.out = out; } public void run () { try { int c = 0; while ( ( c = System.in.read()) > -1 ) { this.out.write(c); } } catch ( IOException e ) { e.printStackTrace(); System.exit(-1); } } } public static void main ( String[] args ) { try { (new TwoWaySerialComm()).connect("COM3"); } catch ( Exception e ) { e.printStackTrace(); } } } From rick_knight at rlknight.com Mon Aug 4 13:25:10 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Mon, 04 Aug 2008 12:25:10 -0700 Subject: [Rxtx] Sun's Comm API? Message-ID: <48975796.4010600@rlknight.com> I have an application that requires the javax compatible version of RXTX and Sun's comm api. I've been able to download and extract the version of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api anywhere. Can someone tell me where I can find it? Or maybe send me a copy? Also, when I try to build RXTX, configure and make complete successfully but make install failes with this error libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 I've never come accross this error before. How can I get past it? Thanks, Rick From bboyes at systronix.com Mon Aug 4 19:10:01 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:10:01 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48975796.4010600@rlknight.com> References: <48975796.4010600@rlknight.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/cb9c6167/attachment-0015.html From bboyes at systronix.com Mon Aug 4 19:12:37 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:12:37 -0600 Subject: [Rxtx] Towards an RXTX release - CSR BT/USB chipset In-Reply-To: <488FB7E7.8000802@gmail.com> References: <460801A4097E3D4CA04CC64EE648584806C56CF0@ism-mail03.corp.ad.wrs.com> <13557-75390@sneakemail.com> <20980-23424@sneakemail.com> <488FB7E7.8000802@gmail.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/52236088/attachment-0015.html From tjarvi at qbang.org Mon Aug 4 19:42:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 19:42:21 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: On Mon, 4 Aug 2008, Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: > I have an application that requires the javax compatible > version of RXTX > and Sun's comm api. I've been able to download and extract > the version > of RXTX that I need (2.0-7pre2) but I can't find Sun's camm > api > anywhere. Can someone tell me where I can find it? Or maybe > send me a > > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm port > support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have just > a ZIP with only the .class JAR file - no source or docs), has a readme > with these comments: > > This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release.? The 2.0.3 release itself is > no longer distributed.? comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project.? The RxTx project (http://www.rxtx.org ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org) was opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support.? Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins.? Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > ? > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > I hope that is helpful! > It would be nice to work with Sun to resolve those longstanding issues. But it may not be practical unless the process goes as fast and painless as the grandfathering of commapi did. Another option may be the old kaffe extensions that moved to gnu classpathx. These don't have the native libraries but should provide the 2.0 interface and the javax.comm.properties mechansim for SPI. http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Mon Aug 4 20:23:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Mon, 04 Aug 2008 20:23:57 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4897B9BD.5070809@ergotech.com> Has there been any work/would it be possible, to layer a javacomm look-alike on top of the GNU code? The goal is not to move the javax code forward, but to emulate the "legacy" javax packages for people who still need this. Jim Trent Jarvi wrote: > On Mon, 4 Aug 2008, Bruce Boyes wrote: > >> At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible >> version of RXTX >> and Sun's comm api. I've been able to download and extract >> the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm >> api >> anywhere. Can someone tell me where I can find it? Or maybe >> send me a >> >> >> javaxcomm has had a sort of on-again off-again history. The windoze >> version has been languishing for years (literally) but there are newer >> versions for other OS's. >> >> We try to keep links on one of our help pages current: >> http://www.practicalembeddedjava.com/tools/javatools_list.html >> which gets you to here: >> http://java.sun.com/products/javacomm/ >> where it says in fact they no longer even support Windows and Mac: >> "Implementations of the API are currently available for Solaris SPARC, >> Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so >> someone could support it. But I guess that's part of the reason RXTX >> exists! >> >> So one of Sun's own products, SunSPOT, has to use RXTX to get comm port >> support. >> >> The version we use is 2.0 from 11/15/1998. I have posted it on our >> website, which is within the terms of the license agreement contained >> therein (as I understand it). >> >> The last version of javaxcomm for Windows, 2.0.3, (for which I have just >> a ZIP with only the .class JAR file - no source or docs), has a readme >> with these comments: >> >> This distribution contains the comm.jar file original part >> of the COMMAPI 2.0.3 release. The 2.0.3 release itself is >> no longer distributed. comm.jar, which contains the comm >> API java class files (eg. Sun's binary implementation of the >> interface classes), is being made available, unsupported, >> with no obligation to fix bugs, at the request of the RXTX >> project. The RxTx project (http://www.rxtx.org ), uses the >> comm.jar class files, but provides their own native library >> components to provide support for other platforms. >> >> The 2.0.3 comm.jar is being provided in this way because >> as of COMMAPI 3.x, the java binary implementation forked and >> became incompatible with the RxTx project's native code. >> Due to the lack of a clear business case, and to resource >> constraints, no additional resources are being >> provided to provide an alternative engineering solution >> at the time of writing. >> >> RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: >> >> Ultimately the COMMAPI would be better served if a Java >> Community Process JSR (http://www.jcp.org) was opened and >> the COMMAPI was rearchitected to provide a more pluggable >> framework to improve cross-platform support. Such an >> architecture would embody a better defined and better >> documented SPI interface, including a way for comm. ports >> to be revealed to the client application through the API >> via platform-aware plugins. Similarly, native code used >> to access comm port in general could be handled more >> flexibly using a plugin model, whereby on any platform, >> multiple native modules could be in use simultaneously. >> >> Since there are now various ways serial ports can be implemented >> and accessed, modular comm. port JNI native libraries would be >> of benefit insofar as removing the burden of over-generalization >> from any single native component, or inversely, by relieving the >> implicit constraint that comm. drivers be accessed only via a >> monolithic mechanism, such as the UNIX vnode interface. >> >> paul.klissner at sun.com >> 6/10/06 >> >> I hope that is helpful! >> > > It would be nice to work with Sun to resolve those longstanding issues. > But it may not be practical unless the process goes as fast and painless > as the grandfathering of commapi did. > > Another option may be the old kaffe extensions that moved to gnu > classpathx. These don't have the native libraries but should provide > the 2.0 interface and the javax.comm.properties mechansim for SPI. > > http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Mon Aug 4 21:09:15 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 21:09:15 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? Message-ID: Hi Jim, I will not step into the javax.comm namespace without Sun's explicite permission. I fully understand the pain point you are trying to address. In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm Linux) - which remains an integral part of rxtx. At the time it was a win for Sun and rxtx. The Sun commapi license is/was fairly clear that rxtx should not step into that namespace. It made sense as Sun was active in that space and rxtx may go into another namespace - it was an experiment in working with Sun. This may sound silly looking at something that happened almost 10 years ago. In a community of respect which Sun helped create, there is no question about what to do. I hope eventually Sun will step up and do a right thing too. I agree that this is hurting the API more than helping it. There are also questions about how to replace the API in the long term which includes HID support which isn't going well so far. Others that can't even look at Sun's javax.comm today and can look at Kaffe's contribution to classpathx can easily work around such restrictions. On Mon, 4 Aug 2008, Jim Redman wrote: > Has there been any work/would it be possible, to layer a javacomm > look-alike on top of the GNU code? > > The goal is not to move the javax code forward, but to emulate the > "legacy" javax packages for people who still need this. > > Jim > > Trent Jarvi wrote: >> >> It would be nice to work with Sun to resolve those longstanding issues. >> But it may not be practical unless the process goes as fast and painless >> as the grandfathering of commapi did. >> >> Another option may be the old kaffe extensions that moved to gnu >> classpathx. These don't have the native libraries but should provide >> the 2.0 interface and the javax.comm.properties mechansim for SPI. >> >> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From florianmanschwetus at gmx.de Tue Aug 5 05:04:46 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 13:04:46 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: References: <48971C1F.9020806@gmx.de> Message-ID: <489833CE.1040801@gmx.de> Just look at sendCommand in this method I have to place a Thread.sleep(20) after each byte send to get working. Even the event based receive doesn't work fine but this could be may stupidness. The specifikation document (it is on the last pages of the manual) for the beamer could be found on: http://www.optoma.co.uk/support.aspx Florian Manschwetus Trent Jarvi schrieb: > > Hi Florian > > Sorry for the top post in advance. I worry you may not see my answer > under all your code :) > > I have not received this email before. This is 500k of code which I > don't have time to read. I can spend about 5 min on each hobby email > and still get to work in the morning. I have a couple suggestions for > how to get an answer. > > First, cut out your comments and extra code so you can demonstrate the > question (I might even glance and see what is wrong then). Don't go for > a working final product. Isolate the problem using a simple program and > then ask with that as an example. If I did what you just did, I'd have > to post 3/4 of a million lines of code :) > > Second, join the rxtx mail-list and ask there. This will give you 100x > more eyes. I'll also read and try to follow. > > -- > taj > > > > On Mon, 4 Aug 2008, Florian Manschwetus wrote: > >> It could be that my university account is blocked by filters so >> resending from here. >> >> >> Topic is to control Optoma HD80 beamer using rs232 serial chat. >> This code is able to detect power state and switch the beamer on / off. >> connected is the beamer using a digitus usb 2.0 serial adapter with an >> FT232 USB-Serial adapter the systems architecture is amd64. >> >> Please take a look in the sendCommand routine i have to place theire >> those Thread.sleep to get it working. >> Now the question is this correct or is there a better way to get this >> working correctly? >> >> In the javadoc coming with the install i found this: >> setBaudBase >> >> public boolean setBaudBase(int BaudBase) >> throws UnsupportedCommOperationException, >> java.io.IOException >> >> Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 >> before using. >> >> could this explain the error? >> I attached my java source and the protocol description for the beamer >> (available on vendor website). >> >> thx, >> Florian Manschwetus >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: TestRS232.java Type: text/x-java Size: 9143 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0030.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0031.bin From michael.erskine at ketech.com Tue Aug 5 05:53:49 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Tue, 5 Aug 2008 12:53:49 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489833CE.1040801@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> > Just look at sendCommand in this method I have to place a > Thread.sleep(20) after each byte send to get working. Even the event > based receive doesn't work fine but this could be may stupidness. Hi Florian, Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. Regards, Michael Erskine. From florianmanschwetus at gmx.de Tue Aug 5 07:28:15 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:28:15 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> Message-ID: <4898556F.8000208@gmx.de> Michael Erskine schrieb: >> Just look at sendCommand in this method I have to place a >> Thread.sleep(20) after each byte send to get working. Even the event >> based receive doesn't work fine but this could be may stupidness. > > Hi Florian, > > Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. > > Regards, > Michael Erskine. > Ok, sounds fine for the receiving problem. But why i have to wait after each byte when sending a command squence? (the for loop in send command) Florian > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/284f350c/attachment-0014.bin From florianmanschwetus at gmx.de Tue Aug 5 07:44:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:44:14 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <4898592E.2020908@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >>> Just look at sendCommand in this method I have to place a >>> Thread.sleep(20) after each byte send to get working. Even the event >>> based receive doesn't work fine but this could be may stupidness. >> >> Hi Florian, >> >> Yes, naturally you'll have to wait for a response from the other end. >> Why not wait for notification from the event thread perhaps using a >> BlockingDeque rather than your LinkedList. Generally I >> try to decouple all input and output streams: in your case your >> application is operating synchronously like the "expect" program >> (http://expect.nist.gov/) so waits (or timeouts) will need to be >> factored in. >> >> Regards, >> Michael Erskine. >> > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) > > Florian Furthermore there is this basic baud with this confusing javadoc entry: public boolean setBaudBase(int BaudBase) throws UnsupportedCommOperationException, java.io.IOException Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 before using. maybe this could explain something Florian >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/006c7425/attachment-0014.bin From jredman at ergotech.com Tue Aug 5 09:13:36 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 05 Aug 2008 09:13:36 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: Message-ID: <48986E20.3060104@ergotech.com> Trent, So two issues: 1) Technically I'm still not sure how easy/practical a layer would be. The problems are always classes like listeners, and wrapping returns of gnu.io classes. I really see it as a "delegate" type of concept. Any thoughts or ideas of the practicality of this approach? The idea is not to modify RXTX. 2) Javax. The javax namespace does seem to be in widespread use outside of Sun (the same is true for the java namespace). The classpath extensions, or some other location, should be interested in a JavaComm implementation even if it does have dependencies on RXTX. Would you have any philosophical objection to an approach like that? Of course, I suspect it might be better if someone with that authority at Sun would admit that the javax namespace is already in the wild and that there is no problem with it being used within RXTX. Jim Trent Jarvi wrote: > Hi Jim, > > I will not step into the javax.comm namespace without Sun's explicite > permission. I fully understand the pain point you are trying to address. > > In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm > Linux) - which remains an integral part of rxtx. At the time it was a win for > Sun and rxtx. > > The Sun commapi license is/was fairly clear that rxtx should not step into that > namespace. It made sense as Sun was active in that space and rxtx may go into > another namespace - it was an experiment in working with Sun. > > This may sound silly looking at something that happened almost 10 years ago. > In a community of respect which Sun helped create, there is no question about > what to do. I hope eventually Sun will step up and do a right thing too. > > I agree that this is hurting the API more than helping it. There are also > questions about how to replace the API in the long term which includes HID > support which isn't going well so far. > > Others that can't even look at Sun's javax.comm today and can look at Kaffe's > contribution to classpathx can easily work around such restrictions. > > On Mon, 4 Aug 2008, Jim Redman wrote: > >> Has there been any work/would it be possible, to layer a javacomm >> look-alike on top of the GNU code? >> >> The goal is not to move the javax code forward, but to emulate the >> "legacy" javax packages for people who still need this. >> >> Jim >> >> Trent Jarvi wrote: >>> It would be nice to work with Sun to resolve those longstanding issues. >>> But it may not be practical unless the process goes as fast and painless >>> as the grandfathering of commapi did. >>> >>> Another option may be the old kaffe extensions that moved to gnu >>> classpathx. These don't have the native libraries but should provide >>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>> >>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From sandeep at genevasoftech.com Tue Aug 5 11:18:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Tue, 05 Aug 2008 22:48:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <48988B6C.5080409@genevasoftech.com> Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. *-- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/ad20f1cb/attachment-0014.html From Martin.Oberhuber at windriver.com Tue Aug 5 13:30:17 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Tue, 5 Aug 2008 21:30:17 +0200 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Sandeep, shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on Sol7 but I've successfully run it on Sol9 and Sol10. Or is your request really about a native 64bit variant? I'm afraid that then you're out of luck since I think that quite a bit of RXTX is not yet ready for 64 bit. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Sandeep Kumar K Sent: Tuesday, August 05, 2008 7:19 PM To: rxtx at qbang.org Subject: [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so for Solaris 9 Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. -- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/81b7f988/attachment-0014.html From tjarvi at qbang.org Tue Aug 5 22:38:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 22:38:34 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 5 Aug 2008, Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built > on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid that > then > you're out of luck since I think that quite a bit of RXTX is not yet > ready > for 64 bit. > While rxtx-2.1-7 probably has problems, The CVS code should be OK for 64 bit Solaris. If it isn't, let me know and I'll find which patch is missing. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Aug 5 23:13:00 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 23:13:00 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48986E20.3060104@ergotech.com> References: <48986E20.3060104@ergotech.com> Message-ID: On Tue, 5 Aug 2008, Jim Redman wrote: > Trent, > > So two issues: > > 1) Technically I'm still not sure how easy/practical a layer would be. The > problems are always classes like listeners, and wrapping returns of gnu.io > classes. I really see it as a "delegate" type of concept. Any thoughts or > ideas of the practicality of this approach? The idea is not to modify RXTX. I have not put too much thought into this. I assume you want what rxtx 2.0 provided to tie into javax.comm implementations. More classes could be added to rxtx 2.1-7 for SPI support. Maintaining rxtx-2.0 could also be handed to someone if they like. > > 2) Javax. The javax namespace does seem to be in widespread use outside of > Sun (the same is true for the java namespace). The classpath extensions, or > some other location, should be interested in a JavaComm implementation even > if it does have dependencies on RXTX. Would you have any philosophical > objection to an approach like that? > No problems. Classpathx would be a possible place to do it. I'd suggest thinking twice about what this involves in practical terms. You would be wanting to revive the 2.0 API while Sun is at 3.0 and grandfathering the JSR. This undermines the main reason (established api) for using the javax.comm namespace and does not leave such a project in a good position. The only win I see here is maintaining support for applications that can't migrate namespaces. Not that that isn't important. At some point it is going to be less work to just edit the bytecode :) Such a javax.comm effort would also be signing up new projects that decided to use the work up for concerns they probably will not understand or expect. That probably isn't a good path to facilitate for new projects at this time. We will put a good faith effort to work well with others but keep in mind the project has limited bandwidth for such efforts. > Of course, I suspect it might be better if someone with that authority at Sun > would admit that the javax namespace is already in the wild and that there is > no problem with it being used within RXTX. > > Jim > > Trent Jarvi wrote: >> Hi Jim, >> >> I will not step into the javax.comm namespace without Sun's explicite >> permission. I fully understand the pain point you are trying to address. >> >> In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java >> Comm Linux) - which remains an integral part of rxtx. At the time it was a >> win for Sun and rxtx. >> >> The Sun commapi license is/was fairly clear that rxtx should not step into >> that namespace. It made sense as Sun was active in that space and rxtx may >> go into another namespace - it was an experiment in working with Sun. >> >> This may sound silly looking at something that happened almost 10 years >> ago. In a community of respect which Sun helped create, there is no >> question about what to do. I hope eventually Sun will step up and do a >> right thing too. >> >> I agree that this is hurting the API more than helping it. There are also >> questions about how to replace the API in the long term which includes HID >> support which isn't going well so far. >> >> Others that can't even look at Sun's javax.comm today and can look at >> Kaffe's contribution to classpathx can easily work around such >> restrictions. >> >> On Mon, 4 Aug 2008, Jim Redman wrote: >> >>> Has there been any work/would it be possible, to layer a javacomm >>> look-alike on top of the GNU code? >>> >>> The goal is not to move the javax code forward, but to emulate the >>> "legacy" javax packages for people who still need this. >>> >>> Jim >>> >>> Trent Jarvi wrote: >>>> It would be nice to work with Sun to resolve those longstanding issues. >>>> But it may not be practical unless the process goes as fast and painless >>>> as the grandfathering of commapi did. >>>> >>>> Another option may be the old kaffe extensions that moved to gnu >>>> classpathx. These don't have the native libraries but should provide >>>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>>> >>>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From sandeep at genevasoftech.com Wed Aug 6 00:03:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Wed, 06 Aug 2008 11:33:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: <48993EB8.30107@genevasoftech.com> Thank you Mr. Martin for your suggestion. The native file which is given in rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am getting the following error . Any suggestions to solve this issue. I am using Solaris SPARC 64 bit machine. ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) thrown while loading gnu.io.RXTXCommDriver Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(Unknown Source) at java.lang.ClassLoader.loadLibrary(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) at com.ReadFromModem.main(ReadFromModem.java:84) * * *Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid > that then > you're out of luck since I think that quite a bit of RXTX is not yet ready > for 64 bit. > > Cheers, > -- > *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > ------------------------------------------------------------------------ > *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On > Behalf Of *Sandeep Kumar K > *Sent:* Tuesday, August 05, 2008 7:19 PM > *To:* rxtx at qbang.org > *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so > for Solaris 9 > > Hi, > > Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 > bit machine. The librxtxSerial.so given in website is for Solaris 8. > > *-- > > Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/1e920343/attachment-0014.html From tjarvi at qbang.org Wed Aug 6 00:21:42 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 00:21:42 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <48993EB8.30107@genevasoftech.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> <48993EB8.30107@genevasoftech.com> Message-ID: Hi Sandeep You may be out of luck unless you can compile the 2.1 src in CVS (requires gnu make and gcc). But you could try the ToyBox(R)(TM) which is a collection of WiLdLy untested cross compiled 2.1-7 binaries covering everything from the ibm z series to embeded arm/ppc. To give an idea how poorly these are tested, I don't even know if z series machines have a serial port. ftp://www.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Solaris They should at least match the binary types. Actually, I think if you use the rxtx jar from CVS with that file, it should 'work' as the fix for 64 bits was in java not the native code. You could just cd rxtx*/src; javac *.java then jar -cf RXTXcomm.jar `find -name \*.class` to create the hybrid which will complain about version information a bit. On Wed, 6 Aug 2008, Sandeep Kumar K wrote: > Thank you Mr. Martin for your suggestion. The native file which is given in > rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am > getting the following error . > Any suggestions to solve this issue. > I am using Solaris SPARC 64 bit machine. > > ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar > java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 > (Possible cause: architecture word > width mismatch) thrown while loading gnu.io.RXTXCommDriver > Exception in thread "main" java.lang.UnsatisfiedLinkError: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF > class: ELFCLASS64 (Possible cause: > architecture word width mismatch) > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(Unknown Source) > at java.lang.ClassLoader.loadLibrary(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > at com.ReadFromModem.main(ReadFromModem.java:84) > > * > * > > *Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > > > Oberhuber, Martin wrote: >> Sandeep, >> shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse >> variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on >> Sol7 but I've successfully run it on Sol9 and Sol10. >> Or is your request really about a native 64bit variant? I'm afraid that >> then >> you're out of luck since I think that quite a bit of RXTX is not yet ready >> for 64 bit. >> Cheers, >> -- >> *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> ------------------------------------------------------------------------ >> *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On >> Behalf Of *Sandeep Kumar K >> *Sent:* Tuesday, August 05, 2008 7:19 PM >> *To:* rxtx at qbang.org >> *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so >> for Solaris 9 >> >> Hi, >> >> Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 >> bit machine. The librxtxSerial.so given in website is for Solaris 8. >> >> *-- >> Thanks & Regards >> >> Sandeep Kumar K >> Sr. Software Engineer >> Geneva Software Technologies >> Whitefield, Bangalore >> Mob : 9880193454* >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> From michael.erskine at ketech.com Wed Aug 6 01:39:28 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 6 Aug 2008 08:39:28 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Florian Manschwetus wrote: > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) Hi Florian, I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. Regards, Michael Erskine. From florianmanschwetus at gmx.de Wed Aug 6 02:53:16 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 06 Aug 2008 10:53:16 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Message-ID: <4899667C.6010706@gmx.de> Michael Erskine schrieb: > Florian Manschwetus wrote: >> Ok, sounds fine for the receiving problem. >> But why i have to wait after each byte when sending a command squence? >> (the for loop in send command) > > Hi Florian, > I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. > > Regards, > Michael Erskine. > correct with a terminal on the other end it works, my idea was that this basic baud has some influence. Could some one explain what it is for? Florian > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/c2b4fa84/attachment-0014.bin From rick_knight at rlknight.com Wed Aug 6 13:01:07 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:01:07 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F4F3.3020707@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > I have an application (Readerware) that uses RXTX with Javax to access the serial port. This used to work fine under previous Linux' and Java, but something has changed, I assume with Java itself , that is causing the application to fail with a link error. The application is not able to find librxtxSerialParallel.so. RXTX supplies librxtxSerial.so and librxtxParallel.so, but not librxtxSerialParallel.so. Where can I get librxtxSerialParallel.so, or do I need it? Is something else causing the lib to not be found? Thanks, Rick Knight From rick_knight at rlknight.com Wed Aug 6 13:17:55 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:17:55 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F8E3.5060400@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Thanks for the reply. The developer of the app I'm trying to use (Readerware) has sent me a copy of the comm.api and I've copied the library (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar into the proper places. When I try to run the application, I get this error... Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: /usr/lib/libSolarisSerialParallel.so: /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not little-endian (Possible cause: endianness mismatch) Caught java.lang.UnsatisfiedLinkError: com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I while loading driver com.sun.comm.SolarisDriver Is there a way around this error? Thanks again, Rick Knight From jlar310 at gmail.com Wed Aug 6 13:37:42 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 14:37:42 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899F8E3.5060400@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > The developer of the app I'm trying to use (Readerware) has sent me a > copy of the comm.api and I've copied the library > (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar > into the proper places. When I try to run the application, I get this > error... > > Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: > /usr/lib/libSolarisSerialParallel.so: > /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not > little-endian (Possible cause: endianness mismatch) > Caught java.lang.UnsatisfiedLinkError: > com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I > > while loading driver com.sun.comm.SolarisDriver > > Is there a way around this error? What host OS are you running? From your original post it looks like 32 bit Linux. The libSolarisSerialParallel.so file is for Sun Solaris and will vary depending on the underlying hardware architecture as well. Sorry for the double post Rick, but I failed to send this to the list the first time... -- Jeff From rick_knight at rlknight.com Wed Aug 6 13:44:29 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:44:29 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: <4899FF1D.9030504@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > > >> The developer of the app I'm trying to use (Readerware) has sent me a >> copy of the comm.api and I've copied the library >> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >> into the proper places. When I try to run the application, I get this >> error... >> >> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >> /usr/lib/libSolarisSerialParallel.so: >> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >> little-endian (Possible cause: endianness mismatch) >> Caught java.lang.UnsatisfiedLinkError: >> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >> >> while loading driver com.sun.comm.SolarisDriver >> >> Is there a way around this error? >> > > What host OS are you running? From your original post it looks like 32 > bit Linux. > > The libSolarisSerialParallel.so file is for Sun Solaris and will vary > depending on the underlying hardware architecture as well. > > I'm running Kubuntu Linux (debian based). It's 32 bit. Rick Knight From jlar310 at gmail.com Wed Aug 6 15:33:23 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 16:33:23 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > I don't think Sun did binary libraries for Linux in the 2.0 version. Can someone with more historical experience than I confirm that? I recently tried to port a Comm API application from Solaris sparc to Linux x86 and likewise could not get my hands on the binary libraries. I eventually just re-wrote the code to use the gnu namespace packages and rxtx 2.1. What I don't understand is why your application vendor does not provide everything you need to run their software. FYI: I have librxtxParallel.so and librxtxSerial.so installed at JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is /usr/java/default which is actually a softlink to /usr/java/jre1.6.0_05. -- Jeff From defiantlew at yahoo.com.au Wed Aug 6 16:29:33 2008 From: defiantlew at yahoo.com.au (Lew L) Date: Thu, 7 Aug 2008 08:29:33 +1000 Subject: [Rxtx] Sun's Comm API Documentation References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> Message-ID: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> As a matter of interest is the Sun Comm API documentation available somewhere? I have tried the Sun site but it seems to have been removed. Unless I have missed the documentation for RXTX? I javadocced the RXTX source but information (to me) is minimal. Somewhere I got the impression that the Sun Comm API docs is, or was, compatible with RXTX, what is the best docs to use in conjuntion with RXTX and where may the be available? Cheers Lew From rick_knight at rlknight.com Wed Aug 6 17:18:33 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:18:33 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A3149.4050306@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff I'm not sure if I posted this here or not, but when I try to build RXTX from source I get this install error... make all-am make[1]: Entering directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' make[1]: Nothing to be done for `all-am'. make[1]: Leaving directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 Can you tell me how to get past this error and get RXTX built and installed? Thanks, Rick From bboyes at systronix.com Wed Aug 6 17:40:12 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Wed, 06 Aug 2008 17:40:12 -0600 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: At 16:29 08/06/2008, Lew L wrote: >As a matter of interest is the Sun Comm API documentation available >somewhere? I have tried the Sun site but it seems to have been removed. It's in the file we have posted, link in prev email (sorry, in a huge hurry right now). Javadocs definitely there. >Unless I have missed the documentation for RXTX? I javadocced the RXTX >source but information (to me) is minimal. >Somewhere I got the impression that the Sun Comm API docs is, or was, >compatible with RXTX, what is the best docs to use in conjuntion with RXTX >and where may the be available? Yeah, this is one of my concerns/beefs. There is little documentation for RXTX and it isn't just the same as javaxcomm. I would be willing to help out writing docs for RXTX! Yes really... esp if we can fix the Bluetooth issues. best regards Bruce >Cheers >Lew > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx ------- WWW.SYSTRONIX.COM ---------- Real embedded Java and much more +1-801-534-1017 Salt Lake City, USA From rick_knight at rlknight.com Wed Aug 6 17:54:08 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:54:08 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A39A0.2090309@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff, I would like for my vendor to switch to rxtx 2.1. It would make things much easier for me. I'm not sure why he's still using the javax compatible code. He's a small operation. Re-writing the code to use gnu namespace sounds like a major overhaul. Was it? Thanks, Rick From tjarvi at qbang.org Wed Aug 6 21:35:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:35:12 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: >> >>> Jeff wrote: >>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>>> >>>> >>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things > much easier for me. I'm not sure why he's still using the javax > compatible code. He's a small operation. Re-writing the code to use gnu > namespace sounds like a major overhaul. Was it? > Hi Jeff, The changes are fairly mechanical. Imports need to change and any explicite use of the namespace needs to change such as catching an exception. The following script was made for maintaining rxtx 2.0 but can apply to other needs. It is in the contrib dir with rxtx source. #!/bin/sh # Don't use! :) # # Sat, 03 May 2003 16:45:08 Modifications from J?rg Weule # Create a ed-cmd for the change of one pattern # case $1 in gnu) X=g/javax_comm/s+javax_comm+gnu_io+g ;; javax) X=g/gnu_io/s+gnu_io+javax_comm+g ;; *) echo;echo;echo From the top rxtx directory run;echo;echo -e \\t./ChangePackage.sh gnu;echo -e \\t\\tor;echo -e \\t./ChangePackage.sh javax;echo;echo; exit 0 ;; esac # # ed will be used to keep the owner and mode of the files unchanged. # We have run the ed-script for the characters '.' '/' as well. # "tr _ $D" do the change. # find . -type f -a -print | grep -v $0 | (while read F ; do ( echo $X; echo $X| tr _ /; echo $X| tr _ .; echo w; echo q ) | ed $F 2>&1 >/dev/null done ) # # Now we do little changes at the Makefiles. Hope that all we need. # find . -name Makefile\* -a -print | (while read F ; do cat < References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: On Thu, 7 Aug 2008, Lew L wrote: > As a matter of interest is the Sun Comm API documentation available > somewhere? I have tried the Sun site but it seems to have been removed. > > Unless I have missed the documentation for RXTX? I javadocced the RXTX > source but information (to me) is minimal. > Somewhere I got the impression that the Sun Comm API docs is, or was, > compatible with RXTX, what is the best docs to use in conjuntion with RXTX > and where may the be available? > Hi Lew, The documentation on Sun's website is accurate. The changes that are problematic in 3.0 are on the backside which rxtx used to plug into. http://java.sun.com/products/javacomm/reference/api/index.html CommPortIdentifier may have some minor differences (judging by the authors notes). -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Aug 6 21:46:08 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:46:08 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > If javax.comm.properties is properly installed and you are using a 2.0 version of Sun's commapi with rxtx 2.0, you should not see the library attempt to load libSolarisSerialParallel.so. Sun CommAPI 3.0 will not work with any version of rxtx as it is hard coded to use the shared library. See the INSTALL file with rxtx-2.0 source for more help with the properties file. -- Trent Jarvi tjarvi at qbang.org From jlar310 at gmail.com Thu Aug 7 06:32:06 2008 From: jlar310 at gmail.com (Jeff) Date: Thu, 7 Aug 2008 07:32:06 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > Jeff wrote: >> >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >> wrote: >> >>> >>> Jeff wrote: >>> >>>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>> wrote: >>>> >>>> >>>> >>>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things much > easier for me. I'm not sure why he's still using the javax compatible code. > He's a small operation. Re-writing the code to use gnu namespace sounds like > a major overhaul. Was it? I found it quite easy. In fact, in order to accommodate the transition, I actually separated all of the code that deals directly with the Comm API or RXTX into a helper class. The helper class was then coded to use reflection to determine which library was available and then instantiate the necessary objects. No direct imports of either library are used. The main application just needs to get it's hands on the IO streams and need not deal directly with the libraries. Other programs may not be so simple... But this doesn't really help you unless your vendor forks over the source code... -- Jeff From rick_knight at rlknight.com Thu Aug 7 09:47:12 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Thu, 07 Aug 2008 08:47:12 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: <489B1900.10108@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >>> wrote: >>> >>> >>>> Jeff wrote: >>>> >>>> >>>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>>> copy of the comm.api and I've copied the library >>>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>>> into the proper places. When I try to run the application, I get this >>>>>> error... >>>>>> >>>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>>> /usr/lib/libSolarisSerialParallel.so: >>>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>>> little-endian (Possible cause: endianness mismatch) >>>>>> Caught java.lang.UnsatisfiedLinkError: >>>>>> >>>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>>> >>>>>> while loading driver com.sun.comm.SolarisDriver >>>>>> >>>>>> Is there a way around this error? >>>>>> >>>>>> >>>>>> >>>>> What host OS are you running? From your original post it looks like 32 >>>>> bit Linux. >>>>> >>>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>>> depending on the underlying hardware architecture as well. >>>>> >>>>> >>>>> >>>>> >>>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>>> >>>> >>>> >>> I don't think Sun did binary libraries for Linux in the 2.0 version. >>> Can someone with more historical experience than I confirm that? >>> >>> I recently tried to port a Comm API application from Solaris sparc to >>> Linux x86 and likewise could not get my hands on the binary libraries. >>> I eventually just re-wrote the code to use the gnu namespace packages >>> and rxtx 2.1. >>> >>> What I don't understand is why your application vendor does not >>> provide everything you need to run their software. >>> >>> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >>> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >>> /usr/java/default which is actually a softlink to >>> /usr/java/jre1.6.0_05. >>> >>> >>> >> Jeff, >> >> I would like for my vendor to switch to rxtx 2.1. It would make things much >> easier for me. I'm not sure why he's still using the javax compatible code. >> He's a small operation. Re-writing the code to use gnu namespace sounds like >> a major overhaul. Was it? >> > > I found it quite easy. In fact, in order to accommodate the > transition, I actually separated all of the code that deals directly > with the Comm API or RXTX into a helper class. The helper class was > then coded to use reflection to determine which library was available > and then instantiate the necessary objects. No direct imports of > either library are used. The main application just needs to get it's > hands on the IO streams and need not deal directly with the libraries. > Other programs may not be so simple... > > But this doesn't really help you unless your vendor forks over the > source code... > > Jeff, This may not help me directly, but I'm going to forward this thread to the vendor. I think he'll be open to making things work. Thanks again, Rick Knight From agusmunioz at gmail.com Thu Aug 7 16:39:51 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Thu, 7 Aug 2008 19:39:51 -0300 Subject: [Rxtx] How to send ack? Message-ID: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Hi, I'm still learning about serial communication and I have some doubts. I've got this question about how to do the following thing in rxtx. I have this hardware that connect to a PC using a serial port. These hardware receives data from a telephone line, proccess it, and then send it forward to the serial port. I've used a program named wincomm that shows what information is send it through the serial port and I have the nex behaviour: The hardware has a buffer where all data is stored, that cannot be sent it through the seria port. The program reads the first data send it by the hardware, and keep reading the same data always. There is a button in the application that says enable Ack, and when I click, then the hardware start to send all the stored information, and all the information is shown. I write a class, using rxtx that reads the serial port, and the same thing happens, it remains reading the same (first) data all the time. And I thing something like the enable Ack I'm missing. How can I do this enable Ack from my java code using rxtx? Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080807/e0a0f9a1/attachment-0012.html From ajmas at sympatico.ca Thu Aug 7 18:26:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 7 Aug 2008 20:26:41 -0400 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: <4BF42297-81E2-4BB8-A89F-1D43588379AE@sympatico.ca> On 6-Aug-08, at 19:40 , Bruce Boyes wrote: >> Unless I have missed the documentation for RXTX? I javadocced the >> RXTX >> source but information (to me) is minimal. >> Somewhere I got the impression that the Sun Comm API docs is, or was, >> compatible with RXTX, what is the best docs to use in conjuntion >> with RXTX >> and where may the be available? > > Yeah, this is one of my concerns/beefs. There is little documentation > for RXTX and it isn't just the same as javaxcomm. > > I would be willing to help out writing docs for RXTX! Yes really... > esp if we can fix the Bluetooth issues. If you want to contribute documentation then the best place to do that is the wiki. If there is anything missing or that could be improved on then please do so. If there are any points that you would like to see improved, for which you don't have the knowledge then ask on the mailing list for a volunteer. Andre From florianmanschwetus at gmx.de Fri Aug 8 03:04:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Fri, 08 Aug 2008 11:04:14 +0200 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Message-ID: <489C0C0E.2020401@gmx.de> Agustin Mu?oz schrieb: > Hi, I'm still learning about serial communication and I have some > doubts. I've got this question about how to do the following thing in rxtx. > I have this hardware that connect to a PC using a serial port. These > hardware receives data from a telephone line, proccess it, and then send > it forward to the serial port. I've used a program named wincomm that > shows what information is send it through the serial port and I have the > nex behaviour: > > The hardware has a buffer where all data is stored, that cannot be sent > it through the seria port. > The program reads the first data send it by the hardware, and keep > reading the same data always. > There is a button in the application that says enable Ack, and when I > click, then the hardware start to send all the stored information, and > all the information is shown. > > I write a class, using rxtx that reads the serial port, and the same > thing happens, it remains reading the same (first) data all the time. > And I thing something like the enable Ack I'm missing. > How can I do this enable Ack from my java code using rxtx? Afaik, a look at man ascii reveals: Okt Dez Hex Char 006 6 06 ACK So, i hope this will do the job: send(6); florian > > Thanks in advance > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/5b4965f8/attachment-0012.bin From agusmunioz at gmail.com Fri Aug 8 16:31:00 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 19:31:00 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <489C0C0E.2020401@gmx.de> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> Message-ID: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Hi Florian, thanks for the answer. By send(6) you mean to get the port OutputStream and write a 6? I try that but it didn't work. Any suggestion? Thanks On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < florianmanschwetus at gmx.de> wrote: > Agustin Mu?oz schrieb: > > Hi, I'm still learning about serial communication and I have some doubts. >> I've got this question about how to do the following thing in rxtx. >> I have this hardware that connect to a PC using a serial port. These >> hardware receives data from a telephone line, proccess it, and then send it >> forward to the serial port. I've used a program named wincomm that shows >> what information is send it through the serial port and I have the nex >> behaviour: >> >> The hardware has a buffer where all data is stored, that cannot be sent >> it through the seria port. >> The program reads the first data send it by the hardware, and keep reading >> the same data always. >> There is a button in the application that says enable Ack, and when I >> click, then the hardware start to send all the stored information, and all >> the information is shown. >> >> I write a class, using rxtx that reads the serial port, and the same thing >> happens, it remains reading the same (first) data all the time. And I thing >> something like the enable Ack I'm missing. >> How can I do this enable Ack from my java code using rxtx? >> > Afaik, a look at man ascii reveals: > Okt Dez Hex Char > 006 6 06 ACK > So, i hope this will do the job: > send(6); > > florian > >> >> Thanks in advance >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/7f3fba42/attachment-0011.html From agusmunioz at gmail.com Fri Aug 8 18:39:27 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 21:39:27 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Message-ID: <988288430808081739x7f9e7889id82591d5a9e2b4f6@mail.gmail.com> Ok, Florian, it works!! my problem was that I've been sending, through the OutputStream, the bytes of 6 as a string: out.write("6".getBytes()); but then I realized that you can write an int on an OuptuStream, so I tried that and It works: out.write(6); Thank you for the guidance!! On Fri, Aug 8, 2008 at 7:31 PM, Agustin Mu?oz wrote: > Hi Florian, thanks for the answer. By send(6) you mean to get the port > OutputStream and write a 6? > > I try that but it didn't work. > > Any suggestion? > > Thanks > > > On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < > florianmanschwetus at gmx.de> wrote: > >> Agustin Mu?oz schrieb: >> >> Hi, I'm still learning about serial communication and I have some doubts. >>> I've got this question about how to do the following thing in rxtx. >>> I have this hardware that connect to a PC using a serial port. These >>> hardware receives data from a telephone line, proccess it, and then send it >>> forward to the serial port. I've used a program named wincomm that shows >>> what information is send it through the serial port and I have the nex >>> behaviour: >>> >>> The hardware has a buffer where all data is stored, that cannot be sent >>> it through the seria port. >>> The program reads the first data send it by the hardware, and keep >>> reading the same data always. >>> There is a button in the application that says enable Ack, and when I >>> click, then the hardware start to send all the stored information, and all >>> the information is shown. >>> >>> I write a class, using rxtx that reads the serial port, and the same >>> thing happens, it remains reading the same (first) data all the time. And I >>> thing something like the enable Ack I'm missing. >>> How can I do this enable Ack from my java code using rxtx? >>> >> Afaik, a look at man ascii reveals: >> Okt Dez Hex Char >> 006 6 06 ACK >> So, i hope this will do the job: >> send(6); >> >> florian >> >>> >>> Thanks in advance >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/b918ab3d/attachment-0011.html From florianmanschwetus at gmx.de Sat Aug 9 00:45:43 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Sat, 09 Aug 2008 08:45:43 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4899667C.6010706@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> Message-ID: <489D3D17.9090209@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >> Florian Manschwetus wrote: >>> Ok, sounds fine for the receiving problem. >>> But why i have to wait after each byte when sending a command squence? >>> (the for loop in send command) >> >> Hi Florian, >> I'd imagine you probably don't! You could send all bytes in one go and >> RXTX would send them. The problem is most probably the other end: >> perhaps it has a really small buffer, some non-standard UART, or a >> crazy timing issue. If you attach a terminal to your output and send >> all the bytes of a command in one go they should appear no problem. >> >> Regards, >> Michael Erskine. >> > correct with a terminal on the other end it works, my idea was that this > basic baud has some influence. Could some one explain what it is for? > > Florian To make it more clear, my problem is that i can't use: outputStream.write(byte[]); => Beamer doesn't understand the sequence. (mostly no answer when he answers then *001) when i use this construct instead: for (int i = 0; i < command.length; i++) { this.outputStream.write(command[i]); try { Thread.sleep(25); } catch (InterruptedException e) { // TODO Auto-generated catch block e.printStackTrace(); } } it works nearly reliable. So what could it be? This Basic Baud is what exactly? Florian -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080809/692304ee/attachment-0011.bin From tjarvi at qbang.org Sat Aug 9 16:37:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Aug 2008 16:37:19 -0600 (MDT) Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489D3D17.9090209@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> <489D3D17.9090209@gmx.de> Message-ID: On Sat, 9 Aug 2008, Florian Manschwetus wrote: > Florian Manschwetus schrieb: >> Michael Erskine schrieb: >>> Florian Manschwetus wrote: >>>> Ok, sounds fine for the receiving problem. >>>> But why i have to wait after each byte when sending a command squence? >>>> (the for loop in send command) >>> >>> Hi Florian, >>> I'd imagine you probably don't! You could send all bytes in one go and >>> RXTX would send them. The problem is most probably the other end: perhaps >>> it has a really small buffer, some non-standard UART, or a crazy timing >>> issue. If you attach a terminal to your output and send all the bytes of a >>> command in one go they should appear no problem. >>> >>> Regards, >>> Michael Erskine. >>> >> correct with a terminal on the other end it works, my idea was that this >> basic baud has some influence. Could some one explain what it is for? >> >> Florian > To make it more clear, > my problem is that i can't use: > outputStream.write(byte[]); > => Beamer doesn't understand the sequence. (mostly no answer when he answers > then *001) > > when i use this construct instead: > > for (int i = 0; i < command.length; i++) { > this.outputStream.write(command[i]); > try { > Thread.sleep(25); > } catch (InterruptedException e) { > // TODO Auto-generated catch block > e.printStackTrace(); > } > } > > it works nearly reliable. > > So what could it be? This Basic Baud is what exactly? > I suspect you are using the 'moon protocol' and don't know it. RXTX enables this by default. The buffer on the other end is first in first out while reading. If the buffer is full, the bits are hand carried to the moon and burried. Then if the other side reads a couple bytes, two more bytes go into the buffer followed by more moon protocol. The resulting array of bytes the other side reads may appear to be scrambled until you go to the moon, get the bits and insert them in the right place. Flow control can prevent the default moon protocol and throttles the communiation by almost writing a byte at a time as need be. Hardware flow control is preferable but software flow control should also work. Read and write can appear to hang if the other side is not connected. This is why we don't enable them all the time. If you can't use flow control, you have to take care with the moon protocol and give the other side time to read. That is what your slower version of write is doing. -- Trent Jarvi tjarvi at qbang.org From rxtx at allenjb.me.uk Mon Aug 11 08:06:36 2008 From: rxtx at allenjb.me.uk (AllenJB) Date: Mon, 11 Aug 2008 15:06:36 +0100 Subject: [Rxtx] Disabling EV_RXFLAG Message-ID: <48A0476C.2090800@allenjb.me.uk> Hi all, I'm working with a device which does not use an EvtChar and need to disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an event mask of FD 01 00 00. The reference software I have uses FB 00 00 00. With the rxtx mask I get framing errors which I believe are caused when the EvtChar is received. Is there currently a way with rxtx (I've using rxtx from Java) to disable EV_RXFLAG? If not from Java, where would I start if I wanted to turn the EV_RXFLAG option off in the C code? I've had a grep of the rxtx source code, but I can't see where EV_RXFLAG is being set. Thanks in advance, AllenJB From tjarvi at qbang.org Mon Aug 11 14:17:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Aug 2008 14:17:27 -0600 (MDT) Subject: [Rxtx] Disabling EV_RXFLAG In-Reply-To: <48A0476C.2090800@allenjb.me.uk> References: <48A0476C.2090800@allenjb.me.uk> Message-ID: On Mon, 11 Aug 2008, AllenJB wrote: > Hi all, > > I'm working with a device which does not use an EvtChar and need to > disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an > event mask of FD 01 00 00. The reference software I have uses FB 00 00 > 00. With the rxtx mask I get framing errors which I believe are caused > when the EvtChar is received. > > Is there currently a way with rxtx (I've using rxtx from Java) to > disable EV_RXFLAG? > > If not from Java, where would I start if I wanted to turn the EV_RXFLAG > option off in the C code? I've had a grep of the rxtx source code, but I > can't see where EV_RXFLAG is being set. > > Thanks in advance, > > AllenJB Hi Allen, I'd look at termios.c::tcsetattr() and termios.c::FillDCB() -- Trent Jarvi tjarvi at qbang.org From superdadusa at gmail.com Tue Aug 12 13:57:32 2008 From: superdadusa at gmail.com (John Choi) Date: Tue, 12 Aug 2008 13:57:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. Message-ID: Hi all, Just let you all know I just start to learn Java. I have download the serial comm package and the source code from open source communities.. I was able to verify with the given message string via serial monitor. when the given message string sends to the serial port then the character return added to the end of string by default if I use "Hello World" however if I changed to something else other than "Hello, World" there is no character return add to the end of string. I thing the library download from rxtx.org has implemented for the special strings. I can do like "login\n" in the string message to make character return but I don't want to add this individual custom character for each command return in every static message string I send, Can any who have done this might help me? Basically, something like this,, Write and add function to the program write a command, Reads the respond from a serial device.. Function handles multiple messages, Write: "com open" Read: Welcome to my world" expected Write: "admin" Read: Password?, expected Write: "admin" Read: you are successfully login terminal, expected. And I need to add a separate function handler handles a character return add to the each command above. If anyone can help this I can do the reset? Thank you in advance, John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0007.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SerialIO.java Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0007.pl From Steffen.DETTMER at ingenico.com Wed Aug 13 02:16:38 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 13 Aug 2008 10:16:38 +0200 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: References: Message-ID: <20080813081638.GA25412@elberon.bln.de.ingenico.com> * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > I can do like "login\n" in the string message to make character > return but I don't want to add this individual custom character > for each command return in every static message string I send, and why not?! > Can any who have done this might help me? what's about with writing a small wrapper function adding the carriage return? However, this would be slow, because either you call write two times (very bad) or the string needs to be copied, \n appended and written (since you are using Java Performance probably isn't so critical). Personally I would write `"login\n"' and `username + "\n"' etc., because since it is part of the command it should be part of the command definition string. > Basically, something like this,, Write and add function to the program write > a command, Reads the respond from a serial device.. correctly reading a `line' is more difficult. If you cannot make assumptions about timeouts and/or you need to have low delay, you need to read byte wise. If you need to save CPU resources you might need to add some buffering layer that you can read byte-wise but that is reading blockwise with some small timeout (lets say for serial lines something around byte transmission time times three or so). > /* > * To change this template, choose Tools | Templates > * and open the template in the editor. > */ :) > package joliba; > > /** > * > * @author root > */ :) > // derived from SUN's examples in the javax.comm package > import java.io.*; > import java.util.*; > //import javax.comm.*; // for SUN's serial/parallel port libraries > import gnu.io.*; // for rxtxSerial library > > public class SerialIO implements Runnable, SerialPortEventListener { > static CommPortIdentifier portId; > static CommPortIdentifier saveportId; > static Enumeration portList; > InputStream inputStream; > SerialPort serialPort; > Thread readThread; You need a thread for your synchronous RPC-style protocol? > static String messageString = "Hello, world!"; > static OutputStream outputStream; > static boolean outputBufferEmptyFlag = false; > > public static void main(String[] args) { > boolean portFound = false; > String defaultPort; > > // determine the name of the serial port on several operating systems > String osname = System.getProperty("os.name","").toLowerCase(); > if ( osname.startsWith("windows") ) { > // windows > defaultPort = "COM1"; > } else if (osname.startsWith("linux")) { > // linux > defaultPort = "/dev/ttyS0"; > } else if ( osname.startsWith("mac") ) { > // mac > defaultPort = "????"; > } else { > System.out.println("Sorry, your operating system is not supported"); > return; > } Is such a construction recommended? Isn't there some abstraction (like COM1 working on any platform)? [...] > try { > // activate the OUTPUT_BUFFER_EMPTY notifier > serialPort.notifyOnOutputEmpty(true); > } catch (Exception e) { > System.out.println("Error setting event notification"); > System.out.println(e.toString()); > System.exit(-1); > } I doubt that -1 is defined, probably some 127 or so would be the result, maybe better simply `throw e'? > public void writetoport() { > System.out.println("Writing \""+messageString+"\" to "+serialPort.getName()); > try { > // write string to serial port > outputStream.write(messageString.getBytes()); > } catch (IOException e) {} > } maybe something like /** * Writes the given output string and an additional carriage * return to the current outputStream. */ public void writeStringToPort( /** The output string (without CR). */ String output ) throws IOException { String outputLine = output + "\n"; outputStream.write(outputLine.getBytes()); } ? > > public SerialIO() { > // initalize serial port > try { > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > } catch (PortInUseException e) {} if the port is in use, you continue? Wonder that this works in Java, I would assume serialPort beeing uninitialized which AFAIK is an error in Java. > try { > inputStream = serialPort.getInputStream(); > } catch (IOException e) {} > > try { > serialPort.addEventListener(this); > } catch (TooManyListenersException e) {} > > // activate the DATA_AVAILABLE notifier > serialPort.notifyOnDataAvailable(true); > > try { > // set port parameters > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > } catch (UnsupportedCommOperationException e) {} > > // start the read thread > readThread = new Thread(this); > readThread.start(); > > } I think in all those exception cases you can abort, because it is unlikely that ignoring those errors allow a successful continuation, so in this case maybe it would be better to add a throw clause to the method. > public void run() { > // first thing in the thread, we initialize the write operation > initwritetoport(); > try { > while (true) { > // write string to port, the serialEvent will read it > writetoport(); > Thread.sleep(1000); > } > } catch (InterruptedException e) {} > } Does this make sense? Your `SimpleReadApp' writes one and the same string each second? > public void serialEvent(SerialPortEvent event) { > switch (event.getEventType()) { > case SerialPortEvent.BI: > case SerialPortEvent.OE: > case SerialPortEvent.FE: > case SerialPortEvent.PE: > case SerialPortEvent.CD: > case SerialPortEvent.CTS: > case SerialPortEvent.DSR: > case SerialPortEvent.RI: > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > break; > case SerialPortEvent.DATA_AVAILABLE: > // we get here if data has been received > byte[] readBuffer = new byte[20]; > try { > // read data > while (inputStream.available() > 0) { > int numBytes = inputStream.read(readBuffer); > } > // print data > String result = new String(readBuffer); > System.out.println("Read: "+result); > } catch (IOException e) {} I doubt that this is correct. I would assume you will get a 20 bytes result always, if more bytes would be available they would be printed in a second line but if less bytes are read I'd assume that the buffer/result contains zero bytes from implicite readBuffer contents initialisation (zero is no string terminator in Java AFAIK). > break; > } > } > } oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From florianmanschwetus at gmx.de Wed Aug 13 06:09:31 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 13 Aug 2008 14:09:31 +0200 Subject: [Rxtx] someone has seen such errors? Message-ID: <48A2CEFB.90007@gmx.de> I mean my communication mostly works, but it is far from perfect could this be the reason? Florian Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/949b9947/attachment-0007.bin From superdadusa at gmail.com Wed Aug 13 08:40:32 2008 From: superdadusa at gmail.com (John Choi) Date: Wed, 13 Aug 2008 08:40:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: <20080813081638.GA25412@elberon.bln.de.ingenico.com> References: <20080813081638.GA25412@elberon.bln.de.ingenico.com> Message-ID: Thank you so much Steffen and I will try that suggestion. John On 8/13/08, Steffen DETTMER wrote: > > * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > > I can do like "login\n" in the string message to make character > > return but I don't want to add this individual custom character > > for each command return in every static message string I send, > > and why not?! > > > Can any who have done this might help me? > > what's about with writing a small wrapper function adding the > carriage return? > However, this would be slow, because either you call write two > times (very bad) or the string needs to be copied, \n appended > and written (since you are using Java Performance probably isn't > so critical). > > Personally I would write `"login\n"' and `username + "\n"' etc., > because since it is part of the command it should be part of the > command definition string. > > > Basically, something like this,, Write and add function to the program > write > > a command, Reads the respond from a serial device.. > > correctly reading a `line' is more difficult. If you cannot make > assumptions about timeouts and/or you need to have low delay, you > need to read byte wise. If you need to save CPU resources you > might need to add some buffering layer that you can read > byte-wise but that is reading blockwise with some small timeout > (lets say for serial lines something around byte transmission > time times three or so). > > > /* > > * To change this template, choose Tools | Templates > > * and open the template in the editor. > > */ > > :) > > > package joliba; > > > > /** > > * > > * @author root > > */ > > :) > > > // derived from SUN's examples in the javax.comm package > > import java.io.*; > > import java.util.*; > > //import javax.comm.*; // for SUN's serial/parallel port libraries > > import gnu.io.*; // for rxtxSerial library > > > > public class SerialIO implements Runnable, SerialPortEventListener { > > static CommPortIdentifier portId; > > static CommPortIdentifier saveportId; > > static Enumeration portList; > > InputStream inputStream; > > SerialPort serialPort; > > Thread readThread; > > You need a thread for your synchronous RPC-style protocol? > > > static String messageString = "Hello, world!"; > > static OutputStream outputStream; > > static boolean outputBufferEmptyFlag = false; > > > > public static void main(String[] args) { > > boolean portFound = false; > > String defaultPort; > > > > // determine the name of the serial port on several operating > systems > > String osname = System.getProperty("os.name","").toLowerCase(); > > if ( osname.startsWith("windows") ) { > > // windows > > defaultPort = "COM1"; > > } else if (osname.startsWith("linux")) { > > // linux > > defaultPort = "/dev/ttyS0"; > > } else if ( osname.startsWith("mac") ) { > > // mac > > defaultPort = "????"; > > } else { > > System.out.println("Sorry, your operating system is not > supported"); > > return; > > } > > Is such a construction recommended? Isn't there some abstraction > (like COM1 working on any platform)? > > [...] > > try { > > // activate the OUTPUT_BUFFER_EMPTY notifier > > serialPort.notifyOnOutputEmpty(true); > > } catch (Exception e) { > > System.out.println("Error setting event notification"); > > System.out.println(e.toString()); > > System.exit(-1); > > } > > I doubt that -1 is defined, probably some 127 or so would be the > result, maybe better simply `throw e'? > > > public void writetoport() { > > System.out.println("Writing \""+messageString+"\" to > "+serialPort.getName()); > > try { > > // write string to serial port > > outputStream.write(messageString.getBytes()); > > } catch (IOException e) {} > > } > > maybe something like > > /** > * Writes the given output string and an additional carriage > * return to the current outputStream. > */ > public void > writeStringToPort( > /** The output string (without CR). */ > String output > ) throws IOException > { > String outputLine = output + "\n"; > outputStream.write(outputLine.getBytes()); > } > > ? > > > > > public SerialIO() { > > // initalize serial port > > try { > > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > > } catch (PortInUseException e) {} > > if the port is in use, you continue? Wonder that this works in > Java, I would assume serialPort beeing uninitialized which AFAIK > is an error in Java. > > > try { > > inputStream = serialPort.getInputStream(); > > } catch (IOException e) {} > > > > try { > > serialPort.addEventListener(this); > > } catch (TooManyListenersException e) {} > > > > // activate the DATA_AVAILABLE notifier > > serialPort.notifyOnDataAvailable(true); > > > > try { > > // set port parameters > > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > } catch (UnsupportedCommOperationException e) {} > > > > // start the read thread > > readThread = new Thread(this); > > readThread.start(); > > > > } > > I think in all those exception cases you can abort, because it is > unlikely that ignoring those errors allow a successful > continuation, so in this case maybe it would be better to add a > throw clause to the method. > > > public void run() { > > // first thing in the thread, we initialize the write operation > > initwritetoport(); > > try { > > while (true) { > > // write string to port, the serialEvent will read it > > writetoport(); > > Thread.sleep(1000); > > } > > } catch (InterruptedException e) {} > > } > > Does this make sense? Your `SimpleReadApp' writes one and the > same string each second? > > > public void serialEvent(SerialPortEvent event) { > > switch (event.getEventType()) { > > case SerialPortEvent.BI: > > case SerialPortEvent.OE: > > case SerialPortEvent.FE: > > case SerialPortEvent.PE: > > case SerialPortEvent.CD: > > case SerialPortEvent.CTS: > > case SerialPortEvent.DSR: > > case SerialPortEvent.RI: > > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > > break; > > case SerialPortEvent.DATA_AVAILABLE: > > // we get here if data has been received > > byte[] readBuffer = new byte[20]; > > try { > > // read data > > while (inputStream.available() > 0) { > > int numBytes = inputStream.read(readBuffer); > > } > > // print data > > String result = new String(readBuffer); > > System.out.println("Read: "+result); > > } catch (IOException e) {} > > I doubt that this is correct. I would assume you will get a 20 > bytes result always, if more bytes would be available they would > be printed in a second line but if less bytes are read I'd assume > that the buffer/result contains zero bytes from implicite > readBuffer contents initialisation (zero is no string terminator > in Java AFAIK). > > > break; > > } > > } > > } > > oki, > > Steffen > > About Ingenico Throughout the world businesses rely on Ingenico for secure > and expedient electronic transaction acceptance. Ingenico products leverage > proven technology, established standards and unparalleled ergonomics to > provide optimal reliability, versatility and usability. This comprehensive > range of products is complemented by a global array of services and > partnerships, enabling businesses in a number of vertical sectors to accept > transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged > information. If you are not the addressee or authorized to receive this for > the addressee, you must not use, copy, disclose or take any action based on > this message or any information herein. If you have received this message in > error, please advise the sender immediately by reply e-mail and delete this > message. Thank you for your cooperation. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/73c4135c/attachment-0006.html From ajmas at sympatico.ca Sat Aug 16 07:15:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 09:15:41 -0400 Subject: [Rxtx] someone has seen such errors? In-Reply-To: <48A2CEFB.90007@gmx.de> References: <48A2CEFB.90007@gmx.de> Message-ID: <43B5E8DA-1D93-4D90-809B-AAF35FF724C5@sympatico.ca> On 13-Aug-08, at 08:09 , Florian Manschwetus wrote: > I mean my communication mostly works, but it is far from perfect > could this be the reason? > > Florian > > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control Judging by the error messages this looks related to the driver you are using. Do a search for the following string with you favourite search engine, it should turn up a few hits: ftdi_set_termios FAILED to set databits/stopbits/parity Andre From ajmas at sympatico.ca Sat Aug 16 19:12:04 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 21:12:04 -0400 Subject: [Rxtx] Using SerialPortEvent? Message-ID: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Hi, Could someone tell me how I should be using the SerialPortEvent? Am I meant to be waiting for data and then simply reading from the inputstream? If this is the case why no just block on an inputstream read? Andr? From tjarvi at qbang.org Sat Aug 16 19:41:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 16 Aug 2008 19:41:13 -0600 (MDT) Subject: [Rxtx] Using SerialPortEvent? In-Reply-To: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> References: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Message-ID: On Sat, 16 Aug 2008, Andre-John Mas wrote: > Hi, > > Could someone tell me how I should be using the SerialPortEvent? Am I > meant to be waiting for data and then simply reading from the > inputstream? If this is the case why no just block on an inputstream > read? > Polling for data is fine also. It really depends upon what you are trying to do. For instance, if you require x bytes before reading, you can start polling after data is available. If you read on the same thread as your GUI and are waiting for data in a read, the results may be less than desirable. Java programming is 'usually' event driven rather than polling based. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sat Aug 16 20:10:39 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 22:10:39 -0400 Subject: [Rxtx] Using SerialPortEvent? In-Reply-To: References: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Message-ID: <3E495D4C-BB28-4845-A6AB-984C9A826BDF@sympatico.ca> On 16-Aug-08, at 21:41 , Trent Jarvi wrote: > On Sat, 16 Aug 2008, Andre-John Mas wrote: > >> Hi, >> >> Could someone tell me how I should be using the SerialPortEvent? Am I >> meant to be waiting for data and then simply reading from the >> inputstream? If this is the case why no just block on an inputstream >> read? >> > > Polling for data is fine also. It really depends upon what you are > trying to do. For instance, if you require x bytes before reading, > you can start polling after data is available. If you read on the > same thread as your GUI and are waiting for data in a read, the > results may be less than desirable. > > Java programming is 'usually' event driven rather than polling based. Sounds good. I thought I would use this opportunity to provide a event based version of the TwoWaySerialComm example. Could you just validate it before I add it to the Wiki: package ajmas74.experimental; import gnu.io.CommPort; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; import gnu.io.SerialPortEvent; import gnu.io.SerialPortEventListener; import java.io.IOException; import java.io.InputStream; import java.io.OutputStream; /** * This version of the TwoWaySerialComm example makes use of the * SerialPortEventListener to avoid polling. * * @author ajmas * */ public class TwoWaySerialComm { public TwoWaySerialComm() { super(); } void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { CommPort commPort = portIdentifier.open(this.getClass().getName(),2000); if ( commPort instanceof SerialPort ) { SerialPort serialPort = (SerialPort) commPort; serialPort .setSerialPortParams (57600 ,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); (new Thread(new SerialWriter(out))).start(); serialPort.addEventListener(new SerialReader(in)); } else { System.out.println("Error: Only serial ports are handled by this example."); } } } /** * Handles the input coming from the serial port. A new line character * is treated as the end of a block in this example. */ public static class SerialReader implements SerialPortEventListener { private InputStream in; private byte[] buffer = new byte[1024]; public SerialReader ( InputStream in ) { this.in = in; } public void serialEvent(SerialPortEvent arg0) { int data; try { int len = 0; while ( ( data = in.read()) > -1 ) { if ( data != '\n' ) { break; } buffer[len++] = (byte) data; } System.out.print(new String(buffer,0,len)); } catch ( IOException e ) { e.printStackTrace(); System.exit(-1); } } } /** */ public static class SerialWriter implements Runnable { OutputStream out; public SerialWriter ( OutputStream out ) { this.out = out; } public void run () { try { int c = 0; while ( ( c = System.in.read()) > -1 ) { this.out.write(c); } } catch ( IOException e ) { e.printStackTrace(); System.exit(-1); } } } public static void main ( String[] args ) { try { (new TwoWaySerialComm()).connect("COM3"); } catch ( Exception e ) { e.printStackTrace(); } } } From rick_knight at rlknight.com Mon Aug 4 13:25:10 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Mon, 04 Aug 2008 12:25:10 -0700 Subject: [Rxtx] Sun's Comm API? Message-ID: <48975796.4010600@rlknight.com> I have an application that requires the javax compatible version of RXTX and Sun's comm api. I've been able to download and extract the version of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api anywhere. Can someone tell me where I can find it? Or maybe send me a copy? Also, when I try to build RXTX, configure and make complete successfully but make install failes with this error libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 I've never come accross this error before. How can I get past it? Thanks, Rick From bboyes at systronix.com Mon Aug 4 19:10:01 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:10:01 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48975796.4010600@rlknight.com> References: <48975796.4010600@rlknight.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/cb9c6167/attachment-0016.html From bboyes at systronix.com Mon Aug 4 19:12:37 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:12:37 -0600 Subject: [Rxtx] Towards an RXTX release - CSR BT/USB chipset In-Reply-To: <488FB7E7.8000802@gmail.com> References: <460801A4097E3D4CA04CC64EE648584806C56CF0@ism-mail03.corp.ad.wrs.com> <13557-75390@sneakemail.com> <20980-23424@sneakemail.com> <488FB7E7.8000802@gmail.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/52236088/attachment-0016.html From tjarvi at qbang.org Mon Aug 4 19:42:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 19:42:21 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: On Mon, 4 Aug 2008, Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: > I have an application that requires the javax compatible > version of RXTX > and Sun's comm api. I've been able to download and extract > the version > of RXTX that I need (2.0-7pre2) but I can't find Sun's camm > api > anywhere. Can someone tell me where I can find it? Or maybe > send me a > > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm port > support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have just > a ZIP with only the .class JAR file - no source or docs), has a readme > with these comments: > > This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release.? The 2.0.3 release itself is > no longer distributed.? comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project.? The RxTx project (http://www.rxtx.org ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org) was opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support.? Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins.? Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > ? > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > I hope that is helpful! > It would be nice to work with Sun to resolve those longstanding issues. But it may not be practical unless the process goes as fast and painless as the grandfathering of commapi did. Another option may be the old kaffe extensions that moved to gnu classpathx. These don't have the native libraries but should provide the 2.0 interface and the javax.comm.properties mechansim for SPI. http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Mon Aug 4 20:23:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Mon, 04 Aug 2008 20:23:57 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4897B9BD.5070809@ergotech.com> Has there been any work/would it be possible, to layer a javacomm look-alike on top of the GNU code? The goal is not to move the javax code forward, but to emulate the "legacy" javax packages for people who still need this. Jim Trent Jarvi wrote: > On Mon, 4 Aug 2008, Bruce Boyes wrote: > >> At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible >> version of RXTX >> and Sun's comm api. I've been able to download and extract >> the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm >> api >> anywhere. Can someone tell me where I can find it? Or maybe >> send me a >> >> >> javaxcomm has had a sort of on-again off-again history. The windoze >> version has been languishing for years (literally) but there are newer >> versions for other OS's. >> >> We try to keep links on one of our help pages current: >> http://www.practicalembeddedjava.com/tools/javatools_list.html >> which gets you to here: >> http://java.sun.com/products/javacomm/ >> where it says in fact they no longer even support Windows and Mac: >> "Implementations of the API are currently available for Solaris SPARC, >> Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so >> someone could support it. But I guess that's part of the reason RXTX >> exists! >> >> So one of Sun's own products, SunSPOT, has to use RXTX to get comm port >> support. >> >> The version we use is 2.0 from 11/15/1998. I have posted it on our >> website, which is within the terms of the license agreement contained >> therein (as I understand it). >> >> The last version of javaxcomm for Windows, 2.0.3, (for which I have just >> a ZIP with only the .class JAR file - no source or docs), has a readme >> with these comments: >> >> This distribution contains the comm.jar file original part >> of the COMMAPI 2.0.3 release. The 2.0.3 release itself is >> no longer distributed. comm.jar, which contains the comm >> API java class files (eg. Sun's binary implementation of the >> interface classes), is being made available, unsupported, >> with no obligation to fix bugs, at the request of the RXTX >> project. The RxTx project (http://www.rxtx.org ), uses the >> comm.jar class files, but provides their own native library >> components to provide support for other platforms. >> >> The 2.0.3 comm.jar is being provided in this way because >> as of COMMAPI 3.x, the java binary implementation forked and >> became incompatible with the RxTx project's native code. >> Due to the lack of a clear business case, and to resource >> constraints, no additional resources are being >> provided to provide an alternative engineering solution >> at the time of writing. >> >> RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: >> >> Ultimately the COMMAPI would be better served if a Java >> Community Process JSR (http://www.jcp.org) was opened and >> the COMMAPI was rearchitected to provide a more pluggable >> framework to improve cross-platform support. Such an >> architecture would embody a better defined and better >> documented SPI interface, including a way for comm. ports >> to be revealed to the client application through the API >> via platform-aware plugins. Similarly, native code used >> to access comm port in general could be handled more >> flexibly using a plugin model, whereby on any platform, >> multiple native modules could be in use simultaneously. >> >> Since there are now various ways serial ports can be implemented >> and accessed, modular comm. port JNI native libraries would be >> of benefit insofar as removing the burden of over-generalization >> from any single native component, or inversely, by relieving the >> implicit constraint that comm. drivers be accessed only via a >> monolithic mechanism, such as the UNIX vnode interface. >> >> paul.klissner at sun.com >> 6/10/06 >> >> I hope that is helpful! >> > > It would be nice to work with Sun to resolve those longstanding issues. > But it may not be practical unless the process goes as fast and painless > as the grandfathering of commapi did. > > Another option may be the old kaffe extensions that moved to gnu > classpathx. These don't have the native libraries but should provide > the 2.0 interface and the javax.comm.properties mechansim for SPI. > > http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Mon Aug 4 21:09:15 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 21:09:15 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? Message-ID: Hi Jim, I will not step into the javax.comm namespace without Sun's explicite permission. I fully understand the pain point you are trying to address. In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm Linux) - which remains an integral part of rxtx. At the time it was a win for Sun and rxtx. The Sun commapi license is/was fairly clear that rxtx should not step into that namespace. It made sense as Sun was active in that space and rxtx may go into another namespace - it was an experiment in working with Sun. This may sound silly looking at something that happened almost 10 years ago. In a community of respect which Sun helped create, there is no question about what to do. I hope eventually Sun will step up and do a right thing too. I agree that this is hurting the API more than helping it. There are also questions about how to replace the API in the long term which includes HID support which isn't going well so far. Others that can't even look at Sun's javax.comm today and can look at Kaffe's contribution to classpathx can easily work around such restrictions. On Mon, 4 Aug 2008, Jim Redman wrote: > Has there been any work/would it be possible, to layer a javacomm > look-alike on top of the GNU code? > > The goal is not to move the javax code forward, but to emulate the > "legacy" javax packages for people who still need this. > > Jim > > Trent Jarvi wrote: >> >> It would be nice to work with Sun to resolve those longstanding issues. >> But it may not be practical unless the process goes as fast and painless >> as the grandfathering of commapi did. >> >> Another option may be the old kaffe extensions that moved to gnu >> classpathx. These don't have the native libraries but should provide >> the 2.0 interface and the javax.comm.properties mechansim for SPI. >> >> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From florianmanschwetus at gmx.de Tue Aug 5 05:04:46 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 13:04:46 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: References: <48971C1F.9020806@gmx.de> Message-ID: <489833CE.1040801@gmx.de> Just look at sendCommand in this method I have to place a Thread.sleep(20) after each byte send to get working. Even the event based receive doesn't work fine but this could be may stupidness. The specifikation document (it is on the last pages of the manual) for the beamer could be found on: http://www.optoma.co.uk/support.aspx Florian Manschwetus Trent Jarvi schrieb: > > Hi Florian > > Sorry for the top post in advance. I worry you may not see my answer > under all your code :) > > I have not received this email before. This is 500k of code which I > don't have time to read. I can spend about 5 min on each hobby email > and still get to work in the morning. I have a couple suggestions for > how to get an answer. > > First, cut out your comments and extra code so you can demonstrate the > question (I might even glance and see what is wrong then). Don't go for > a working final product. Isolate the problem using a simple program and > then ask with that as an example. If I did what you just did, I'd have > to post 3/4 of a million lines of code :) > > Second, join the rxtx mail-list and ask there. This will give you 100x > more eyes. I'll also read and try to follow. > > -- > taj > > > > On Mon, 4 Aug 2008, Florian Manschwetus wrote: > >> It could be that my university account is blocked by filters so >> resending from here. >> >> >> Topic is to control Optoma HD80 beamer using rs232 serial chat. >> This code is able to detect power state and switch the beamer on / off. >> connected is the beamer using a digitus usb 2.0 serial adapter with an >> FT232 USB-Serial adapter the systems architecture is amd64. >> >> Please take a look in the sendCommand routine i have to place theire >> those Thread.sleep to get it working. >> Now the question is this correct or is there a better way to get this >> working correctly? >> >> In the javadoc coming with the install i found this: >> setBaudBase >> >> public boolean setBaudBase(int BaudBase) >> throws UnsupportedCommOperationException, >> java.io.IOException >> >> Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 >> before using. >> >> could this explain the error? >> I attached my java source and the protocol description for the beamer >> (available on vendor website). >> >> thx, >> Florian Manschwetus >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: TestRS232.java Type: text/x-java Size: 9143 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0032.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0033.bin From michael.erskine at ketech.com Tue Aug 5 05:53:49 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Tue, 5 Aug 2008 12:53:49 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489833CE.1040801@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> > Just look at sendCommand in this method I have to place a > Thread.sleep(20) after each byte send to get working. Even the event > based receive doesn't work fine but this could be may stupidness. Hi Florian, Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. Regards, Michael Erskine. From florianmanschwetus at gmx.de Tue Aug 5 07:28:15 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:28:15 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> Message-ID: <4898556F.8000208@gmx.de> Michael Erskine schrieb: >> Just look at sendCommand in this method I have to place a >> Thread.sleep(20) after each byte send to get working. Even the event >> based receive doesn't work fine but this could be may stupidness. > > Hi Florian, > > Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. > > Regards, > Michael Erskine. > Ok, sounds fine for the receiving problem. But why i have to wait after each byte when sending a command squence? (the for loop in send command) Florian > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/284f350c/attachment-0015.bin From florianmanschwetus at gmx.de Tue Aug 5 07:44:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:44:14 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <4898592E.2020908@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >>> Just look at sendCommand in this method I have to place a >>> Thread.sleep(20) after each byte send to get working. Even the event >>> based receive doesn't work fine but this could be may stupidness. >> >> Hi Florian, >> >> Yes, naturally you'll have to wait for a response from the other end. >> Why not wait for notification from the event thread perhaps using a >> BlockingDeque rather than your LinkedList. Generally I >> try to decouple all input and output streams: in your case your >> application is operating synchronously like the "expect" program >> (http://expect.nist.gov/) so waits (or timeouts) will need to be >> factored in. >> >> Regards, >> Michael Erskine. >> > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) > > Florian Furthermore there is this basic baud with this confusing javadoc entry: public boolean setBaudBase(int BaudBase) throws UnsupportedCommOperationException, java.io.IOException Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 before using. maybe this could explain something Florian >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/006c7425/attachment-0015.bin From jredman at ergotech.com Tue Aug 5 09:13:36 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 05 Aug 2008 09:13:36 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: Message-ID: <48986E20.3060104@ergotech.com> Trent, So two issues: 1) Technically I'm still not sure how easy/practical a layer would be. The problems are always classes like listeners, and wrapping returns of gnu.io classes. I really see it as a "delegate" type of concept. Any thoughts or ideas of the practicality of this approach? The idea is not to modify RXTX. 2) Javax. The javax namespace does seem to be in widespread use outside of Sun (the same is true for the java namespace). The classpath extensions, or some other location, should be interested in a JavaComm implementation even if it does have dependencies on RXTX. Would you have any philosophical objection to an approach like that? Of course, I suspect it might be better if someone with that authority at Sun would admit that the javax namespace is already in the wild and that there is no problem with it being used within RXTX. Jim Trent Jarvi wrote: > Hi Jim, > > I will not step into the javax.comm namespace without Sun's explicite > permission. I fully understand the pain point you are trying to address. > > In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm > Linux) - which remains an integral part of rxtx. At the time it was a win for > Sun and rxtx. > > The Sun commapi license is/was fairly clear that rxtx should not step into that > namespace. It made sense as Sun was active in that space and rxtx may go into > another namespace - it was an experiment in working with Sun. > > This may sound silly looking at something that happened almost 10 years ago. > In a community of respect which Sun helped create, there is no question about > what to do. I hope eventually Sun will step up and do a right thing too. > > I agree that this is hurting the API more than helping it. There are also > questions about how to replace the API in the long term which includes HID > support which isn't going well so far. > > Others that can't even look at Sun's javax.comm today and can look at Kaffe's > contribution to classpathx can easily work around such restrictions. > > On Mon, 4 Aug 2008, Jim Redman wrote: > >> Has there been any work/would it be possible, to layer a javacomm >> look-alike on top of the GNU code? >> >> The goal is not to move the javax code forward, but to emulate the >> "legacy" javax packages for people who still need this. >> >> Jim >> >> Trent Jarvi wrote: >>> It would be nice to work with Sun to resolve those longstanding issues. >>> But it may not be practical unless the process goes as fast and painless >>> as the grandfathering of commapi did. >>> >>> Another option may be the old kaffe extensions that moved to gnu >>> classpathx. These don't have the native libraries but should provide >>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>> >>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From sandeep at genevasoftech.com Tue Aug 5 11:18:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Tue, 05 Aug 2008 22:48:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <48988B6C.5080409@genevasoftech.com> Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. *-- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/ad20f1cb/attachment-0015.html From Martin.Oberhuber at windriver.com Tue Aug 5 13:30:17 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Tue, 5 Aug 2008 21:30:17 +0200 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Sandeep, shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on Sol7 but I've successfully run it on Sol9 and Sol10. Or is your request really about a native 64bit variant? I'm afraid that then you're out of luck since I think that quite a bit of RXTX is not yet ready for 64 bit. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Sandeep Kumar K Sent: Tuesday, August 05, 2008 7:19 PM To: rxtx at qbang.org Subject: [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so for Solaris 9 Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. -- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/81b7f988/attachment-0015.html From tjarvi at qbang.org Tue Aug 5 22:38:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 22:38:34 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 5 Aug 2008, Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built > on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid that > then > you're out of luck since I think that quite a bit of RXTX is not yet > ready > for 64 bit. > While rxtx-2.1-7 probably has problems, The CVS code should be OK for 64 bit Solaris. If it isn't, let me know and I'll find which patch is missing. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Aug 5 23:13:00 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 23:13:00 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48986E20.3060104@ergotech.com> References: <48986E20.3060104@ergotech.com> Message-ID: On Tue, 5 Aug 2008, Jim Redman wrote: > Trent, > > So two issues: > > 1) Technically I'm still not sure how easy/practical a layer would be. The > problems are always classes like listeners, and wrapping returns of gnu.io > classes. I really see it as a "delegate" type of concept. Any thoughts or > ideas of the practicality of this approach? The idea is not to modify RXTX. I have not put too much thought into this. I assume you want what rxtx 2.0 provided to tie into javax.comm implementations. More classes could be added to rxtx 2.1-7 for SPI support. Maintaining rxtx-2.0 could also be handed to someone if they like. > > 2) Javax. The javax namespace does seem to be in widespread use outside of > Sun (the same is true for the java namespace). The classpath extensions, or > some other location, should be interested in a JavaComm implementation even > if it does have dependencies on RXTX. Would you have any philosophical > objection to an approach like that? > No problems. Classpathx would be a possible place to do it. I'd suggest thinking twice about what this involves in practical terms. You would be wanting to revive the 2.0 API while Sun is at 3.0 and grandfathering the JSR. This undermines the main reason (established api) for using the javax.comm namespace and does not leave such a project in a good position. The only win I see here is maintaining support for applications that can't migrate namespaces. Not that that isn't important. At some point it is going to be less work to just edit the bytecode :) Such a javax.comm effort would also be signing up new projects that decided to use the work up for concerns they probably will not understand or expect. That probably isn't a good path to facilitate for new projects at this time. We will put a good faith effort to work well with others but keep in mind the project has limited bandwidth for such efforts. > Of course, I suspect it might be better if someone with that authority at Sun > would admit that the javax namespace is already in the wild and that there is > no problem with it being used within RXTX. > > Jim > > Trent Jarvi wrote: >> Hi Jim, >> >> I will not step into the javax.comm namespace without Sun's explicite >> permission. I fully understand the pain point you are trying to address. >> >> In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java >> Comm Linux) - which remains an integral part of rxtx. At the time it was a >> win for Sun and rxtx. >> >> The Sun commapi license is/was fairly clear that rxtx should not step into >> that namespace. It made sense as Sun was active in that space and rxtx may >> go into another namespace - it was an experiment in working with Sun. >> >> This may sound silly looking at something that happened almost 10 years >> ago. In a community of respect which Sun helped create, there is no >> question about what to do. I hope eventually Sun will step up and do a >> right thing too. >> >> I agree that this is hurting the API more than helping it. There are also >> questions about how to replace the API in the long term which includes HID >> support which isn't going well so far. >> >> Others that can't even look at Sun's javax.comm today and can look at >> Kaffe's contribution to classpathx can easily work around such >> restrictions. >> >> On Mon, 4 Aug 2008, Jim Redman wrote: >> >>> Has there been any work/would it be possible, to layer a javacomm >>> look-alike on top of the GNU code? >>> >>> The goal is not to move the javax code forward, but to emulate the >>> "legacy" javax packages for people who still need this. >>> >>> Jim >>> >>> Trent Jarvi wrote: >>>> It would be nice to work with Sun to resolve those longstanding issues. >>>> But it may not be practical unless the process goes as fast and painless >>>> as the grandfathering of commapi did. >>>> >>>> Another option may be the old kaffe extensions that moved to gnu >>>> classpathx. These don't have the native libraries but should provide >>>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>>> >>>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From sandeep at genevasoftech.com Wed Aug 6 00:03:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Wed, 06 Aug 2008 11:33:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: <48993EB8.30107@genevasoftech.com> Thank you Mr. Martin for your suggestion. The native file which is given in rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am getting the following error . Any suggestions to solve this issue. I am using Solaris SPARC 64 bit machine. ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) thrown while loading gnu.io.RXTXCommDriver Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(Unknown Source) at java.lang.ClassLoader.loadLibrary(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) at com.ReadFromModem.main(ReadFromModem.java:84) * * *Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid > that then > you're out of luck since I think that quite a bit of RXTX is not yet ready > for 64 bit. > > Cheers, > -- > *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > ------------------------------------------------------------------------ > *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On > Behalf Of *Sandeep Kumar K > *Sent:* Tuesday, August 05, 2008 7:19 PM > *To:* rxtx at qbang.org > *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so > for Solaris 9 > > Hi, > > Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 > bit machine. The librxtxSerial.so given in website is for Solaris 8. > > *-- > > Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/1e920343/attachment-0015.html From tjarvi at qbang.org Wed Aug 6 00:21:42 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 00:21:42 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <48993EB8.30107@genevasoftech.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> <48993EB8.30107@genevasoftech.com> Message-ID: Hi Sandeep You may be out of luck unless you can compile the 2.1 src in CVS (requires gnu make and gcc). But you could try the ToyBox(R)(TM) which is a collection of WiLdLy untested cross compiled 2.1-7 binaries covering everything from the ibm z series to embeded arm/ppc. To give an idea how poorly these are tested, I don't even know if z series machines have a serial port. ftp://www.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Solaris They should at least match the binary types. Actually, I think if you use the rxtx jar from CVS with that file, it should 'work' as the fix for 64 bits was in java not the native code. You could just cd rxtx*/src; javac *.java then jar -cf RXTXcomm.jar `find -name \*.class` to create the hybrid which will complain about version information a bit. On Wed, 6 Aug 2008, Sandeep Kumar K wrote: > Thank you Mr. Martin for your suggestion. The native file which is given in > rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am > getting the following error . > Any suggestions to solve this issue. > I am using Solaris SPARC 64 bit machine. > > ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar > java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 > (Possible cause: architecture word > width mismatch) thrown while loading gnu.io.RXTXCommDriver > Exception in thread "main" java.lang.UnsatisfiedLinkError: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF > class: ELFCLASS64 (Possible cause: > architecture word width mismatch) > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(Unknown Source) > at java.lang.ClassLoader.loadLibrary(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > at com.ReadFromModem.main(ReadFromModem.java:84) > > * > * > > *Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > > > Oberhuber, Martin wrote: >> Sandeep, >> shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse >> variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on >> Sol7 but I've successfully run it on Sol9 and Sol10. >> Or is your request really about a native 64bit variant? I'm afraid that >> then >> you're out of luck since I think that quite a bit of RXTX is not yet ready >> for 64 bit. >> Cheers, >> -- >> *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> ------------------------------------------------------------------------ >> *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On >> Behalf Of *Sandeep Kumar K >> *Sent:* Tuesday, August 05, 2008 7:19 PM >> *To:* rxtx at qbang.org >> *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so >> for Solaris 9 >> >> Hi, >> >> Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 >> bit machine. The librxtxSerial.so given in website is for Solaris 8. >> >> *-- >> Thanks & Regards >> >> Sandeep Kumar K >> Sr. Software Engineer >> Geneva Software Technologies >> Whitefield, Bangalore >> Mob : 9880193454* >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> From michael.erskine at ketech.com Wed Aug 6 01:39:28 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 6 Aug 2008 08:39:28 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Florian Manschwetus wrote: > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) Hi Florian, I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. Regards, Michael Erskine. From florianmanschwetus at gmx.de Wed Aug 6 02:53:16 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 06 Aug 2008 10:53:16 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Message-ID: <4899667C.6010706@gmx.de> Michael Erskine schrieb: > Florian Manschwetus wrote: >> Ok, sounds fine for the receiving problem. >> But why i have to wait after each byte when sending a command squence? >> (the for loop in send command) > > Hi Florian, > I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. > > Regards, > Michael Erskine. > correct with a terminal on the other end it works, my idea was that this basic baud has some influence. Could some one explain what it is for? Florian > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/c2b4fa84/attachment-0015.bin From rick_knight at rlknight.com Wed Aug 6 13:01:07 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:01:07 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F4F3.3020707@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > I have an application (Readerware) that uses RXTX with Javax to access the serial port. This used to work fine under previous Linux' and Java, but something has changed, I assume with Java itself , that is causing the application to fail with a link error. The application is not able to find librxtxSerialParallel.so. RXTX supplies librxtxSerial.so and librxtxParallel.so, but not librxtxSerialParallel.so. Where can I get librxtxSerialParallel.so, or do I need it? Is something else causing the lib to not be found? Thanks, Rick Knight From rick_knight at rlknight.com Wed Aug 6 13:17:55 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:17:55 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F8E3.5060400@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Thanks for the reply. The developer of the app I'm trying to use (Readerware) has sent me a copy of the comm.api and I've copied the library (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar into the proper places. When I try to run the application, I get this error... Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: /usr/lib/libSolarisSerialParallel.so: /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not little-endian (Possible cause: endianness mismatch) Caught java.lang.UnsatisfiedLinkError: com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I while loading driver com.sun.comm.SolarisDriver Is there a way around this error? Thanks again, Rick Knight From jlar310 at gmail.com Wed Aug 6 13:37:42 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 14:37:42 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899F8E3.5060400@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > The developer of the app I'm trying to use (Readerware) has sent me a > copy of the comm.api and I've copied the library > (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar > into the proper places. When I try to run the application, I get this > error... > > Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: > /usr/lib/libSolarisSerialParallel.so: > /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not > little-endian (Possible cause: endianness mismatch) > Caught java.lang.UnsatisfiedLinkError: > com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I > > while loading driver com.sun.comm.SolarisDriver > > Is there a way around this error? What host OS are you running? From your original post it looks like 32 bit Linux. The libSolarisSerialParallel.so file is for Sun Solaris and will vary depending on the underlying hardware architecture as well. Sorry for the double post Rick, but I failed to send this to the list the first time... -- Jeff From rick_knight at rlknight.com Wed Aug 6 13:44:29 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:44:29 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: <4899FF1D.9030504@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > > >> The developer of the app I'm trying to use (Readerware) has sent me a >> copy of the comm.api and I've copied the library >> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >> into the proper places. When I try to run the application, I get this >> error... >> >> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >> /usr/lib/libSolarisSerialParallel.so: >> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >> little-endian (Possible cause: endianness mismatch) >> Caught java.lang.UnsatisfiedLinkError: >> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >> >> while loading driver com.sun.comm.SolarisDriver >> >> Is there a way around this error? >> > > What host OS are you running? From your original post it looks like 32 > bit Linux. > > The libSolarisSerialParallel.so file is for Sun Solaris and will vary > depending on the underlying hardware architecture as well. > > I'm running Kubuntu Linux (debian based). It's 32 bit. Rick Knight From jlar310 at gmail.com Wed Aug 6 15:33:23 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 16:33:23 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > I don't think Sun did binary libraries for Linux in the 2.0 version. Can someone with more historical experience than I confirm that? I recently tried to port a Comm API application from Solaris sparc to Linux x86 and likewise could not get my hands on the binary libraries. I eventually just re-wrote the code to use the gnu namespace packages and rxtx 2.1. What I don't understand is why your application vendor does not provide everything you need to run their software. FYI: I have librxtxParallel.so and librxtxSerial.so installed at JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is /usr/java/default which is actually a softlink to /usr/java/jre1.6.0_05. -- Jeff From defiantlew at yahoo.com.au Wed Aug 6 16:29:33 2008 From: defiantlew at yahoo.com.au (Lew L) Date: Thu, 7 Aug 2008 08:29:33 +1000 Subject: [Rxtx] Sun's Comm API Documentation References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> Message-ID: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> As a matter of interest is the Sun Comm API documentation available somewhere? I have tried the Sun site but it seems to have been removed. Unless I have missed the documentation for RXTX? I javadocced the RXTX source but information (to me) is minimal. Somewhere I got the impression that the Sun Comm API docs is, or was, compatible with RXTX, what is the best docs to use in conjuntion with RXTX and where may the be available? Cheers Lew From rick_knight at rlknight.com Wed Aug 6 17:18:33 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:18:33 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A3149.4050306@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff I'm not sure if I posted this here or not, but when I try to build RXTX from source I get this install error... make all-am make[1]: Entering directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' make[1]: Nothing to be done for `all-am'. make[1]: Leaving directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 Can you tell me how to get past this error and get RXTX built and installed? Thanks, Rick From bboyes at systronix.com Wed Aug 6 17:40:12 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Wed, 06 Aug 2008 17:40:12 -0600 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: At 16:29 08/06/2008, Lew L wrote: >As a matter of interest is the Sun Comm API documentation available >somewhere? I have tried the Sun site but it seems to have been removed. It's in the file we have posted, link in prev email (sorry, in a huge hurry right now). Javadocs definitely there. >Unless I have missed the documentation for RXTX? I javadocced the RXTX >source but information (to me) is minimal. >Somewhere I got the impression that the Sun Comm API docs is, or was, >compatible with RXTX, what is the best docs to use in conjuntion with RXTX >and where may the be available? Yeah, this is one of my concerns/beefs. There is little documentation for RXTX and it isn't just the same as javaxcomm. I would be willing to help out writing docs for RXTX! Yes really... esp if we can fix the Bluetooth issues. best regards Bruce >Cheers >Lew > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx ------- WWW.SYSTRONIX.COM ---------- Real embedded Java and much more +1-801-534-1017 Salt Lake City, USA From rick_knight at rlknight.com Wed Aug 6 17:54:08 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:54:08 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A39A0.2090309@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff, I would like for my vendor to switch to rxtx 2.1. It would make things much easier for me. I'm not sure why he's still using the javax compatible code. He's a small operation. Re-writing the code to use gnu namespace sounds like a major overhaul. Was it? Thanks, Rick From tjarvi at qbang.org Wed Aug 6 21:35:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:35:12 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: >> >>> Jeff wrote: >>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>>> >>>> >>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things > much easier for me. I'm not sure why he's still using the javax > compatible code. He's a small operation. Re-writing the code to use gnu > namespace sounds like a major overhaul. Was it? > Hi Jeff, The changes are fairly mechanical. Imports need to change and any explicite use of the namespace needs to change such as catching an exception. The following script was made for maintaining rxtx 2.0 but can apply to other needs. It is in the contrib dir with rxtx source. #!/bin/sh # Don't use! :) # # Sat, 03 May 2003 16:45:08 Modifications from J?rg Weule # Create a ed-cmd for the change of one pattern # case $1 in gnu) X=g/javax_comm/s+javax_comm+gnu_io+g ;; javax) X=g/gnu_io/s+gnu_io+javax_comm+g ;; *) echo;echo;echo From the top rxtx directory run;echo;echo -e \\t./ChangePackage.sh gnu;echo -e \\t\\tor;echo -e \\t./ChangePackage.sh javax;echo;echo; exit 0 ;; esac # # ed will be used to keep the owner and mode of the files unchanged. # We have run the ed-script for the characters '.' '/' as well. # "tr _ $D" do the change. # find . -type f -a -print | grep -v $0 | (while read F ; do ( echo $X; echo $X| tr _ /; echo $X| tr _ .; echo w; echo q ) | ed $F 2>&1 >/dev/null done ) # # Now we do little changes at the Makefiles. Hope that all we need. # find . -name Makefile\* -a -print | (while read F ; do cat < References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: On Thu, 7 Aug 2008, Lew L wrote: > As a matter of interest is the Sun Comm API documentation available > somewhere? I have tried the Sun site but it seems to have been removed. > > Unless I have missed the documentation for RXTX? I javadocced the RXTX > source but information (to me) is minimal. > Somewhere I got the impression that the Sun Comm API docs is, or was, > compatible with RXTX, what is the best docs to use in conjuntion with RXTX > and where may the be available? > Hi Lew, The documentation on Sun's website is accurate. The changes that are problematic in 3.0 are on the backside which rxtx used to plug into. http://java.sun.com/products/javacomm/reference/api/index.html CommPortIdentifier may have some minor differences (judging by the authors notes). -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Aug 6 21:46:08 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:46:08 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > If javax.comm.properties is properly installed and you are using a 2.0 version of Sun's commapi with rxtx 2.0, you should not see the library attempt to load libSolarisSerialParallel.so. Sun CommAPI 3.0 will not work with any version of rxtx as it is hard coded to use the shared library. See the INSTALL file with rxtx-2.0 source for more help with the properties file. -- Trent Jarvi tjarvi at qbang.org From jlar310 at gmail.com Thu Aug 7 06:32:06 2008 From: jlar310 at gmail.com (Jeff) Date: Thu, 7 Aug 2008 07:32:06 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > Jeff wrote: >> >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >> wrote: >> >>> >>> Jeff wrote: >>> >>>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>> wrote: >>>> >>>> >>>> >>>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things much > easier for me. I'm not sure why he's still using the javax compatible code. > He's a small operation. Re-writing the code to use gnu namespace sounds like > a major overhaul. Was it? I found it quite easy. In fact, in order to accommodate the transition, I actually separated all of the code that deals directly with the Comm API or RXTX into a helper class. The helper class was then coded to use reflection to determine which library was available and then instantiate the necessary objects. No direct imports of either library are used. The main application just needs to get it's hands on the IO streams and need not deal directly with the libraries. Other programs may not be so simple... But this doesn't really help you unless your vendor forks over the source code... -- Jeff From rick_knight at rlknight.com Thu Aug 7 09:47:12 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Thu, 07 Aug 2008 08:47:12 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: <489B1900.10108@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >>> wrote: >>> >>> >>>> Jeff wrote: >>>> >>>> >>>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>>> copy of the comm.api and I've copied the library >>>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>>> into the proper places. When I try to run the application, I get this >>>>>> error... >>>>>> >>>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>>> /usr/lib/libSolarisSerialParallel.so: >>>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>>> little-endian (Possible cause: endianness mismatch) >>>>>> Caught java.lang.UnsatisfiedLinkError: >>>>>> >>>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>>> >>>>>> while loading driver com.sun.comm.SolarisDriver >>>>>> >>>>>> Is there a way around this error? >>>>>> >>>>>> >>>>>> >>>>> What host OS are you running? From your original post it looks like 32 >>>>> bit Linux. >>>>> >>>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>>> depending on the underlying hardware architecture as well. >>>>> >>>>> >>>>> >>>>> >>>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>>> >>>> >>>> >>> I don't think Sun did binary libraries for Linux in the 2.0 version. >>> Can someone with more historical experience than I confirm that? >>> >>> I recently tried to port a Comm API application from Solaris sparc to >>> Linux x86 and likewise could not get my hands on the binary libraries. >>> I eventually just re-wrote the code to use the gnu namespace packages >>> and rxtx 2.1. >>> >>> What I don't understand is why your application vendor does not >>> provide everything you need to run their software. >>> >>> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >>> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >>> /usr/java/default which is actually a softlink to >>> /usr/java/jre1.6.0_05. >>> >>> >>> >> Jeff, >> >> I would like for my vendor to switch to rxtx 2.1. It would make things much >> easier for me. I'm not sure why he's still using the javax compatible code. >> He's a small operation. Re-writing the code to use gnu namespace sounds like >> a major overhaul. Was it? >> > > I found it quite easy. In fact, in order to accommodate the > transition, I actually separated all of the code that deals directly > with the Comm API or RXTX into a helper class. The helper class was > then coded to use reflection to determine which library was available > and then instantiate the necessary objects. No direct imports of > either library are used. The main application just needs to get it's > hands on the IO streams and need not deal directly with the libraries. > Other programs may not be so simple... > > But this doesn't really help you unless your vendor forks over the > source code... > > Jeff, This may not help me directly, but I'm going to forward this thread to the vendor. I think he'll be open to making things work. Thanks again, Rick Knight From agusmunioz at gmail.com Thu Aug 7 16:39:51 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Thu, 7 Aug 2008 19:39:51 -0300 Subject: [Rxtx] How to send ack? Message-ID: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Hi, I'm still learning about serial communication and I have some doubts. I've got this question about how to do the following thing in rxtx. I have this hardware that connect to a PC using a serial port. These hardware receives data from a telephone line, proccess it, and then send it forward to the serial port. I've used a program named wincomm that shows what information is send it through the serial port and I have the nex behaviour: The hardware has a buffer where all data is stored, that cannot be sent it through the seria port. The program reads the first data send it by the hardware, and keep reading the same data always. There is a button in the application that says enable Ack, and when I click, then the hardware start to send all the stored information, and all the information is shown. I write a class, using rxtx that reads the serial port, and the same thing happens, it remains reading the same (first) data all the time. And I thing something like the enable Ack I'm missing. How can I do this enable Ack from my java code using rxtx? Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080807/e0a0f9a1/attachment-0013.html From ajmas at sympatico.ca Thu Aug 7 18:26:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 7 Aug 2008 20:26:41 -0400 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: <4BF42297-81E2-4BB8-A89F-1D43588379AE@sympatico.ca> On 6-Aug-08, at 19:40 , Bruce Boyes wrote: >> Unless I have missed the documentation for RXTX? I javadocced the >> RXTX >> source but information (to me) is minimal. >> Somewhere I got the impression that the Sun Comm API docs is, or was, >> compatible with RXTX, what is the best docs to use in conjuntion >> with RXTX >> and where may the be available? > > Yeah, this is one of my concerns/beefs. There is little documentation > for RXTX and it isn't just the same as javaxcomm. > > I would be willing to help out writing docs for RXTX! Yes really... > esp if we can fix the Bluetooth issues. If you want to contribute documentation then the best place to do that is the wiki. If there is anything missing or that could be improved on then please do so. If there are any points that you would like to see improved, for which you don't have the knowledge then ask on the mailing list for a volunteer. Andre From florianmanschwetus at gmx.de Fri Aug 8 03:04:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Fri, 08 Aug 2008 11:04:14 +0200 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Message-ID: <489C0C0E.2020401@gmx.de> Agustin Mu?oz schrieb: > Hi, I'm still learning about serial communication and I have some > doubts. I've got this question about how to do the following thing in rxtx. > I have this hardware that connect to a PC using a serial port. These > hardware receives data from a telephone line, proccess it, and then send > it forward to the serial port. I've used a program named wincomm that > shows what information is send it through the serial port and I have the > nex behaviour: > > The hardware has a buffer where all data is stored, that cannot be sent > it through the seria port. > The program reads the first data send it by the hardware, and keep > reading the same data always. > There is a button in the application that says enable Ack, and when I > click, then the hardware start to send all the stored information, and > all the information is shown. > > I write a class, using rxtx that reads the serial port, and the same > thing happens, it remains reading the same (first) data all the time. > And I thing something like the enable Ack I'm missing. > How can I do this enable Ack from my java code using rxtx? Afaik, a look at man ascii reveals: Okt Dez Hex Char 006 6 06 ACK So, i hope this will do the job: send(6); florian > > Thanks in advance > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/5b4965f8/attachment-0013.bin From agusmunioz at gmail.com Fri Aug 8 16:31:00 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 19:31:00 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <489C0C0E.2020401@gmx.de> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> Message-ID: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Hi Florian, thanks for the answer. By send(6) you mean to get the port OutputStream and write a 6? I try that but it didn't work. Any suggestion? Thanks On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < florianmanschwetus at gmx.de> wrote: > Agustin Mu?oz schrieb: > > Hi, I'm still learning about serial communication and I have some doubts. >> I've got this question about how to do the following thing in rxtx. >> I have this hardware that connect to a PC using a serial port. These >> hardware receives data from a telephone line, proccess it, and then send it >> forward to the serial port. I've used a program named wincomm that shows >> what information is send it through the serial port and I have the nex >> behaviour: >> >> The hardware has a buffer where all data is stored, that cannot be sent >> it through the seria port. >> The program reads the first data send it by the hardware, and keep reading >> the same data always. >> There is a button in the application that says enable Ack, and when I >> click, then the hardware start to send all the stored information, and all >> the information is shown. >> >> I write a class, using rxtx that reads the serial port, and the same thing >> happens, it remains reading the same (first) data all the time. And I thing >> something like the enable Ack I'm missing. >> How can I do this enable Ack from my java code using rxtx? >> > Afaik, a look at man ascii reveals: > Okt Dez Hex Char > 006 6 06 ACK > So, i hope this will do the job: > send(6); > > florian > >> >> Thanks in advance >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/7f3fba42/attachment-0012.html From agusmunioz at gmail.com Fri Aug 8 18:39:27 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 21:39:27 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Message-ID: <988288430808081739x7f9e7889id82591d5a9e2b4f6@mail.gmail.com> Ok, Florian, it works!! my problem was that I've been sending, through the OutputStream, the bytes of 6 as a string: out.write("6".getBytes()); but then I realized that you can write an int on an OuptuStream, so I tried that and It works: out.write(6); Thank you for the guidance!! On Fri, Aug 8, 2008 at 7:31 PM, Agustin Mu?oz wrote: > Hi Florian, thanks for the answer. By send(6) you mean to get the port > OutputStream and write a 6? > > I try that but it didn't work. > > Any suggestion? > > Thanks > > > On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < > florianmanschwetus at gmx.de> wrote: > >> Agustin Mu?oz schrieb: >> >> Hi, I'm still learning about serial communication and I have some doubts. >>> I've got this question about how to do the following thing in rxtx. >>> I have this hardware that connect to a PC using a serial port. These >>> hardware receives data from a telephone line, proccess it, and then send it >>> forward to the serial port. I've used a program named wincomm that shows >>> what information is send it through the serial port and I have the nex >>> behaviour: >>> >>> The hardware has a buffer where all data is stored, that cannot be sent >>> it through the seria port. >>> The program reads the first data send it by the hardware, and keep >>> reading the same data always. >>> There is a button in the application that says enable Ack, and when I >>> click, then the hardware start to send all the stored information, and all >>> the information is shown. >>> >>> I write a class, using rxtx that reads the serial port, and the same >>> thing happens, it remains reading the same (first) data all the time. And I >>> thing something like the enable Ack I'm missing. >>> How can I do this enable Ack from my java code using rxtx? >>> >> Afaik, a look at man ascii reveals: >> Okt Dez Hex Char >> 006 6 06 ACK >> So, i hope this will do the job: >> send(6); >> >> florian >> >>> >>> Thanks in advance >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/b918ab3d/attachment-0012.html From florianmanschwetus at gmx.de Sat Aug 9 00:45:43 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Sat, 09 Aug 2008 08:45:43 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4899667C.6010706@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> Message-ID: <489D3D17.9090209@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >> Florian Manschwetus wrote: >>> Ok, sounds fine for the receiving problem. >>> But why i have to wait after each byte when sending a command squence? >>> (the for loop in send command) >> >> Hi Florian, >> I'd imagine you probably don't! You could send all bytes in one go and >> RXTX would send them. The problem is most probably the other end: >> perhaps it has a really small buffer, some non-standard UART, or a >> crazy timing issue. If you attach a terminal to your output and send >> all the bytes of a command in one go they should appear no problem. >> >> Regards, >> Michael Erskine. >> > correct with a terminal on the other end it works, my idea was that this > basic baud has some influence. Could some one explain what it is for? > > Florian To make it more clear, my problem is that i can't use: outputStream.write(byte[]); => Beamer doesn't understand the sequence. (mostly no answer when he answers then *001) when i use this construct instead: for (int i = 0; i < command.length; i++) { this.outputStream.write(command[i]); try { Thread.sleep(25); } catch (InterruptedException e) { // TODO Auto-generated catch block e.printStackTrace(); } } it works nearly reliable. So what could it be? This Basic Baud is what exactly? Florian -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080809/692304ee/attachment-0012.bin From tjarvi at qbang.org Sat Aug 9 16:37:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Aug 2008 16:37:19 -0600 (MDT) Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489D3D17.9090209@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> <489D3D17.9090209@gmx.de> Message-ID: On Sat, 9 Aug 2008, Florian Manschwetus wrote: > Florian Manschwetus schrieb: >> Michael Erskine schrieb: >>> Florian Manschwetus wrote: >>>> Ok, sounds fine for the receiving problem. >>>> But why i have to wait after each byte when sending a command squence? >>>> (the for loop in send command) >>> >>> Hi Florian, >>> I'd imagine you probably don't! You could send all bytes in one go and >>> RXTX would send them. The problem is most probably the other end: perhaps >>> it has a really small buffer, some non-standard UART, or a crazy timing >>> issue. If you attach a terminal to your output and send all the bytes of a >>> command in one go they should appear no problem. >>> >>> Regards, >>> Michael Erskine. >>> >> correct with a terminal on the other end it works, my idea was that this >> basic baud has some influence. Could some one explain what it is for? >> >> Florian > To make it more clear, > my problem is that i can't use: > outputStream.write(byte[]); > => Beamer doesn't understand the sequence. (mostly no answer when he answers > then *001) > > when i use this construct instead: > > for (int i = 0; i < command.length; i++) { > this.outputStream.write(command[i]); > try { > Thread.sleep(25); > } catch (InterruptedException e) { > // TODO Auto-generated catch block > e.printStackTrace(); > } > } > > it works nearly reliable. > > So what could it be? This Basic Baud is what exactly? > I suspect you are using the 'moon protocol' and don't know it. RXTX enables this by default. The buffer on the other end is first in first out while reading. If the buffer is full, the bits are hand carried to the moon and burried. Then if the other side reads a couple bytes, two more bytes go into the buffer followed by more moon protocol. The resulting array of bytes the other side reads may appear to be scrambled until you go to the moon, get the bits and insert them in the right place. Flow control can prevent the default moon protocol and throttles the communiation by almost writing a byte at a time as need be. Hardware flow control is preferable but software flow control should also work. Read and write can appear to hang if the other side is not connected. This is why we don't enable them all the time. If you can't use flow control, you have to take care with the moon protocol and give the other side time to read. That is what your slower version of write is doing. -- Trent Jarvi tjarvi at qbang.org From rxtx at allenjb.me.uk Mon Aug 11 08:06:36 2008 From: rxtx at allenjb.me.uk (AllenJB) Date: Mon, 11 Aug 2008 15:06:36 +0100 Subject: [Rxtx] Disabling EV_RXFLAG Message-ID: <48A0476C.2090800@allenjb.me.uk> Hi all, I'm working with a device which does not use an EvtChar and need to disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an event mask of FD 01 00 00. The reference software I have uses FB 00 00 00. With the rxtx mask I get framing errors which I believe are caused when the EvtChar is received. Is there currently a way with rxtx (I've using rxtx from Java) to disable EV_RXFLAG? If not from Java, where would I start if I wanted to turn the EV_RXFLAG option off in the C code? I've had a grep of the rxtx source code, but I can't see where EV_RXFLAG is being set. Thanks in advance, AllenJB From tjarvi at qbang.org Mon Aug 11 14:17:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Aug 2008 14:17:27 -0600 (MDT) Subject: [Rxtx] Disabling EV_RXFLAG In-Reply-To: <48A0476C.2090800@allenjb.me.uk> References: <48A0476C.2090800@allenjb.me.uk> Message-ID: On Mon, 11 Aug 2008, AllenJB wrote: > Hi all, > > I'm working with a device which does not use an EvtChar and need to > disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an > event mask of FD 01 00 00. The reference software I have uses FB 00 00 > 00. With the rxtx mask I get framing errors which I believe are caused > when the EvtChar is received. > > Is there currently a way with rxtx (I've using rxtx from Java) to > disable EV_RXFLAG? > > If not from Java, where would I start if I wanted to turn the EV_RXFLAG > option off in the C code? I've had a grep of the rxtx source code, but I > can't see where EV_RXFLAG is being set. > > Thanks in advance, > > AllenJB Hi Allen, I'd look at termios.c::tcsetattr() and termios.c::FillDCB() -- Trent Jarvi tjarvi at qbang.org From superdadusa at gmail.com Tue Aug 12 13:57:32 2008 From: superdadusa at gmail.com (John Choi) Date: Tue, 12 Aug 2008 13:57:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. Message-ID: Hi all, Just let you all know I just start to learn Java. I have download the serial comm package and the source code from open source communities.. I was able to verify with the given message string via serial monitor. when the given message string sends to the serial port then the character return added to the end of string by default if I use "Hello World" however if I changed to something else other than "Hello, World" there is no character return add to the end of string. I thing the library download from rxtx.org has implemented for the special strings. I can do like "login\n" in the string message to make character return but I don't want to add this individual custom character for each command return in every static message string I send, Can any who have done this might help me? Basically, something like this,, Write and add function to the program write a command, Reads the respond from a serial device.. Function handles multiple messages, Write: "com open" Read: Welcome to my world" expected Write: "admin" Read: Password?, expected Write: "admin" Read: you are successfully login terminal, expected. And I need to add a separate function handler handles a character return add to the each command above. If anyone can help this I can do the reset? Thank you in advance, John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0008.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SerialIO.java Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0008.pl From Steffen.DETTMER at ingenico.com Wed Aug 13 02:16:38 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 13 Aug 2008 10:16:38 +0200 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: References: Message-ID: <20080813081638.GA25412@elberon.bln.de.ingenico.com> * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > I can do like "login\n" in the string message to make character > return but I don't want to add this individual custom character > for each command return in every static message string I send, and why not?! > Can any who have done this might help me? what's about with writing a small wrapper function adding the carriage return? However, this would be slow, because either you call write two times (very bad) or the string needs to be copied, \n appended and written (since you are using Java Performance probably isn't so critical). Personally I would write `"login\n"' and `username + "\n"' etc., because since it is part of the command it should be part of the command definition string. > Basically, something like this,, Write and add function to the program write > a command, Reads the respond from a serial device.. correctly reading a `line' is more difficult. If you cannot make assumptions about timeouts and/or you need to have low delay, you need to read byte wise. If you need to save CPU resources you might need to add some buffering layer that you can read byte-wise but that is reading blockwise with some small timeout (lets say for serial lines something around byte transmission time times three or so). > /* > * To change this template, choose Tools | Templates > * and open the template in the editor. > */ :) > package joliba; > > /** > * > * @author root > */ :) > // derived from SUN's examples in the javax.comm package > import java.io.*; > import java.util.*; > //import javax.comm.*; // for SUN's serial/parallel port libraries > import gnu.io.*; // for rxtxSerial library > > public class SerialIO implements Runnable, SerialPortEventListener { > static CommPortIdentifier portId; > static CommPortIdentifier saveportId; > static Enumeration portList; > InputStream inputStream; > SerialPort serialPort; > Thread readThread; You need a thread for your synchronous RPC-style protocol? > static String messageString = "Hello, world!"; > static OutputStream outputStream; > static boolean outputBufferEmptyFlag = false; > > public static void main(String[] args) { > boolean portFound = false; > String defaultPort; > > // determine the name of the serial port on several operating systems > String osname = System.getProperty("os.name","").toLowerCase(); > if ( osname.startsWith("windows") ) { > // windows > defaultPort = "COM1"; > } else if (osname.startsWith("linux")) { > // linux > defaultPort = "/dev/ttyS0"; > } else if ( osname.startsWith("mac") ) { > // mac > defaultPort = "????"; > } else { > System.out.println("Sorry, your operating system is not supported"); > return; > } Is such a construction recommended? Isn't there some abstraction (like COM1 working on any platform)? [...] > try { > // activate the OUTPUT_BUFFER_EMPTY notifier > serialPort.notifyOnOutputEmpty(true); > } catch (Exception e) { > System.out.println("Error setting event notification"); > System.out.println(e.toString()); > System.exit(-1); > } I doubt that -1 is defined, probably some 127 or so would be the result, maybe better simply `throw e'? > public void writetoport() { > System.out.println("Writing \""+messageString+"\" to "+serialPort.getName()); > try { > // write string to serial port > outputStream.write(messageString.getBytes()); > } catch (IOException e) {} > } maybe something like /** * Writes the given output string and an additional carriage * return to the current outputStream. */ public void writeStringToPort( /** The output string (without CR). */ String output ) throws IOException { String outputLine = output + "\n"; outputStream.write(outputLine.getBytes()); } ? > > public SerialIO() { > // initalize serial port > try { > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > } catch (PortInUseException e) {} if the port is in use, you continue? Wonder that this works in Java, I would assume serialPort beeing uninitialized which AFAIK is an error in Java. > try { > inputStream = serialPort.getInputStream(); > } catch (IOException e) {} > > try { > serialPort.addEventListener(this); > } catch (TooManyListenersException e) {} > > // activate the DATA_AVAILABLE notifier > serialPort.notifyOnDataAvailable(true); > > try { > // set port parameters > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > } catch (UnsupportedCommOperationException e) {} > > // start the read thread > readThread = new Thread(this); > readThread.start(); > > } I think in all those exception cases you can abort, because it is unlikely that ignoring those errors allow a successful continuation, so in this case maybe it would be better to add a throw clause to the method. > public void run() { > // first thing in the thread, we initialize the write operation > initwritetoport(); > try { > while (true) { > // write string to port, the serialEvent will read it > writetoport(); > Thread.sleep(1000); > } > } catch (InterruptedException e) {} > } Does this make sense? Your `SimpleReadApp' writes one and the same string each second? > public void serialEvent(SerialPortEvent event) { > switch (event.getEventType()) { > case SerialPortEvent.BI: > case SerialPortEvent.OE: > case SerialPortEvent.FE: > case SerialPortEvent.PE: > case SerialPortEvent.CD: > case SerialPortEvent.CTS: > case SerialPortEvent.DSR: > case SerialPortEvent.RI: > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > break; > case SerialPortEvent.DATA_AVAILABLE: > // we get here if data has been received > byte[] readBuffer = new byte[20]; > try { > // read data > while (inputStream.available() > 0) { > int numBytes = inputStream.read(readBuffer); > } > // print data > String result = new String(readBuffer); > System.out.println("Read: "+result); > } catch (IOException e) {} I doubt that this is correct. I would assume you will get a 20 bytes result always, if more bytes would be available they would be printed in a second line but if less bytes are read I'd assume that the buffer/result contains zero bytes from implicite readBuffer contents initialisation (zero is no string terminator in Java AFAIK). > break; > } > } > } oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From florianmanschwetus at gmx.de Wed Aug 13 06:09:31 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 13 Aug 2008 14:09:31 +0200 Subject: [Rxtx] someone has seen such errors? Message-ID: <48A2CEFB.90007@gmx.de> I mean my communication mostly works, but it is far from perfect could this be the reason? Florian Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/949b9947/attachment-0008.bin From superdadusa at gmail.com Wed Aug 13 08:40:32 2008 From: superdadusa at gmail.com (John Choi) Date: Wed, 13 Aug 2008 08:40:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: <20080813081638.GA25412@elberon.bln.de.ingenico.com> References: <20080813081638.GA25412@elberon.bln.de.ingenico.com> Message-ID: Thank you so much Steffen and I will try that suggestion. John On 8/13/08, Steffen DETTMER wrote: > > * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > > I can do like "login\n" in the string message to make character > > return but I don't want to add this individual custom character > > for each command return in every static message string I send, > > and why not?! > > > Can any who have done this might help me? > > what's about with writing a small wrapper function adding the > carriage return? > However, this would be slow, because either you call write two > times (very bad) or the string needs to be copied, \n appended > and written (since you are using Java Performance probably isn't > so critical). > > Personally I would write `"login\n"' and `username + "\n"' etc., > because since it is part of the command it should be part of the > command definition string. > > > Basically, something like this,, Write and add function to the program > write > > a command, Reads the respond from a serial device.. > > correctly reading a `line' is more difficult. If you cannot make > assumptions about timeouts and/or you need to have low delay, you > need to read byte wise. If you need to save CPU resources you > might need to add some buffering layer that you can read > byte-wise but that is reading blockwise with some small timeout > (lets say for serial lines something around byte transmission > time times three or so). > > > /* > > * To change this template, choose Tools | Templates > > * and open the template in the editor. > > */ > > :) > > > package joliba; > > > > /** > > * > > * @author root > > */ > > :) > > > // derived from SUN's examples in the javax.comm package > > import java.io.*; > > import java.util.*; > > //import javax.comm.*; // for SUN's serial/parallel port libraries > > import gnu.io.*; // for rxtxSerial library > > > > public class SerialIO implements Runnable, SerialPortEventListener { > > static CommPortIdentifier portId; > > static CommPortIdentifier saveportId; > > static Enumeration portList; > > InputStream inputStream; > > SerialPort serialPort; > > Thread readThread; > > You need a thread for your synchronous RPC-style protocol? > > > static String messageString = "Hello, world!"; > > static OutputStream outputStream; > > static boolean outputBufferEmptyFlag = false; > > > > public static void main(String[] args) { > > boolean portFound = false; > > String defaultPort; > > > > // determine the name of the serial port on several operating > systems > > String osname = System.getProperty("os.name","").toLowerCase(); > > if ( osname.startsWith("windows") ) { > > // windows > > defaultPort = "COM1"; > > } else if (osname.startsWith("linux")) { > > // linux > > defaultPort = "/dev/ttyS0"; > > } else if ( osname.startsWith("mac") ) { > > // mac > > defaultPort = "????"; > > } else { > > System.out.println("Sorry, your operating system is not > supported"); > > return; > > } > > Is such a construction recommended? Isn't there some abstraction > (like COM1 working on any platform)? > > [...] > > try { > > // activate the OUTPUT_BUFFER_EMPTY notifier > > serialPort.notifyOnOutputEmpty(true); > > } catch (Exception e) { > > System.out.println("Error setting event notification"); > > System.out.println(e.toString()); > > System.exit(-1); > > } > > I doubt that -1 is defined, probably some 127 or so would be the > result, maybe better simply `throw e'? > > > public void writetoport() { > > System.out.println("Writing \""+messageString+"\" to > "+serialPort.getName()); > > try { > > // write string to serial port > > outputStream.write(messageString.getBytes()); > > } catch (IOException e) {} > > } > > maybe something like > > /** > * Writes the given output string and an additional carriage > * return to the current outputStream. > */ > public void > writeStringToPort( > /** The output string (without CR). */ > String output > ) throws IOException > { > String outputLine = output + "\n"; > outputStream.write(outputLine.getBytes()); > } > > ? > > > > > public SerialIO() { > > // initalize serial port > > try { > > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > > } catch (PortInUseException e) {} > > if the port is in use, you continue? Wonder that this works in > Java, I would assume serialPort beeing uninitialized which AFAIK > is an error in Java. > > > try { > > inputStream = serialPort.getInputStream(); > > } catch (IOException e) {} > > > > try { > > serialPort.addEventListener(this); > > } catch (TooManyListenersException e) {} > > > > // activate the DATA_AVAILABLE notifier > > serialPort.notifyOnDataAvailable(true); > > > > try { > > // set port parameters > > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > } catch (UnsupportedCommOperationException e) {} > > > > // start the read thread > > readThread = new Thread(this); > > readThread.start(); > > > > } > > I think in all those exception cases you can abort, because it is > unlikely that ignoring those errors allow a successful > continuation, so in this case maybe it would be better to add a > throw clause to the method. > > > public void run() { > > // first thing in the thread, we initialize the write operation > > initwritetoport(); > > try { > > while (true) { > > // write string to port, the serialEvent will read it > > writetoport(); > > Thread.sleep(1000); > > } > > } catch (InterruptedException e) {} > > } > > Does this make sense? Your `SimpleReadApp' writes one and the > same string each second? > > > public void serialEvent(SerialPortEvent event) { > > switch (event.getEventType()) { > > case SerialPortEvent.BI: > > case SerialPortEvent.OE: > > case SerialPortEvent.FE: > > case SerialPortEvent.PE: > > case SerialPortEvent.CD: > > case SerialPortEvent.CTS: > > case SerialPortEvent.DSR: > > case SerialPortEvent.RI: > > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > > break; > > case SerialPortEvent.DATA_AVAILABLE: > > // we get here if data has been received > > byte[] readBuffer = new byte[20]; > > try { > > // read data > > while (inputStream.available() > 0) { > > int numBytes = inputStream.read(readBuffer); > > } > > // print data > > String result = new String(readBuffer); > > System.out.println("Read: "+result); > > } catch (IOException e) {} > > I doubt that this is correct. I would assume you will get a 20 > bytes result always, if more bytes would be available they would > be printed in a second line but if less bytes are read I'd assume > that the buffer/result contains zero bytes from implicite > readBuffer contents initialisation (zero is no string terminator > in Java AFAIK). > > > break; > > } > > } > > } > > oki, > > Steffen > > About Ingenico Throughout the world businesses rely on Ingenico for secure > and expedient electronic transaction acceptance. Ingenico products leverage > proven technology, established standards and unparalleled ergonomics to > provide optimal reliability, versatility and usability. This comprehensive > range of products is complemented by a global array of services and > partnerships, enabling businesses in a number of vertical sectors to accept > transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged > information. If you are not the addressee or authorized to receive this for > the addressee, you must not use, copy, disclose or take any action based on > this message or any information herein. If you have received this message in > error, please advise the sender immediately by reply e-mail and delete this > message. Thank you for your cooperation. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/73c4135c/attachment-0007.html From ajmas at sympatico.ca Sat Aug 16 07:15:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 09:15:41 -0400 Subject: [Rxtx] someone has seen such errors? In-Reply-To: <48A2CEFB.90007@gmx.de> References: <48A2CEFB.90007@gmx.de> Message-ID: <43B5E8DA-1D93-4D90-809B-AAF35FF724C5@sympatico.ca> On 13-Aug-08, at 08:09 , Florian Manschwetus wrote: > I mean my communication mostly works, but it is far from perfect > could this be the reason? > > Florian > > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control Judging by the error messages this looks related to the driver you are using. Do a search for the following string with you favourite search engine, it should turn up a few hits: ftdi_set_termios FAILED to set databits/stopbits/parity Andre From ajmas at sympatico.ca Sat Aug 16 19:12:04 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 21:12:04 -0400 Subject: [Rxtx] Using SerialPortEvent? Message-ID: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Hi, Could someone tell me how I should be using the SerialPortEvent? Am I meant to be waiting for data and then simply reading from the inputstream? If this is the case why no just block on an inputstream read? Andr? From tjarvi at qbang.org Sat Aug 16 19:41:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 16 Aug 2008 19:41:13 -0600 (MDT) Subject: [Rxtx] Using SerialPortEvent? In-Reply-To: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> References: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Message-ID: On Sat, 16 Aug 2008, Andre-John Mas wrote: > Hi, > > Could someone tell me how I should be using the SerialPortEvent? Am I > meant to be waiting for data and then simply reading from the > inputstream? If this is the case why no just block on an inputstream > read? > Polling for data is fine also. It really depends upon what you are trying to do. For instance, if you require x bytes before reading, you can start polling after data is available. If you read on the same thread as your GUI and are waiting for data in a read, the results may be less than desirable. Java programming is 'usually' event driven rather than polling based. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sat Aug 16 20:10:39 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 22:10:39 -0400 Subject: [Rxtx] Using SerialPortEvent? In-Reply-To: References: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Message-ID: <3E495D4C-BB28-4845-A6AB-984C9A826BDF@sympatico.ca> On 16-Aug-08, at 21:41 , Trent Jarvi wrote: > On Sat, 16 Aug 2008, Andre-John Mas wrote: > >> Hi, >> >> Could someone tell me how I should be using the SerialPortEvent? Am I >> meant to be waiting for data and then simply reading from the >> inputstream? If this is the case why no just block on an inputstream >> read? >> > > Polling for data is fine also. It really depends upon what you are > trying to do. For instance, if you require x bytes before reading, > you can start polling after data is available. If you read on the > same thread as your GUI and are waiting for data in a read, the > results may be less than desirable. > > Java programming is 'usually' event driven rather than polling based. Sounds good. I thought I would use this opportunity to provide a event based version of the TwoWaySerialComm example. Could you just validate it before I add it to the Wiki: package ajmas74.experimental; import gnu.io.CommPort; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; import gnu.io.SerialPortEvent; import gnu.io.SerialPortEventListener; import java.io.IOException; import java.io.InputStream; import java.io.OutputStream; /** * This version of the TwoWaySerialComm example makes use of the * SerialPortEventListener to avoid polling. * * @author ajmas * */ public class TwoWaySerialComm { public TwoWaySerialComm() { super(); } void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { CommPort commPort = portIdentifier.open(this.getClass().getName(),2000); if ( commPort instanceof SerialPort ) { SerialPort serialPort = (SerialPort) commPort; serialPort .setSerialPortParams (57600 ,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); (new Thread(new SerialWriter(out))).start(); serialPort.addEventListener(new SerialReader(in)); } else { System.out.println("Error: Only serial ports are handled by this example."); } } } /** * Handles the input coming from the serial port. A new line character * is treated as the end of a block in this example. */ public static class SerialReader implements SerialPortEventListener { private InputStream in; private byte[] buffer = new byte[1024]; public SerialReader ( InputStream in ) { this.in = in; } public void serialEvent(SerialPortEvent arg0) { int data; try { int len = 0; while ( ( data = in.read()) > -1 ) { if ( data != '\n' ) { break; } buffer[len++] = (byte) data; } System.out.print(new String(buffer,0,len)); } catch ( IOException e ) { e.printStackTrace(); System.exit(-1); } } } /** */ public static class SerialWriter implements Runnable { OutputStream out; public SerialWriter ( OutputStream out ) { this.out = out; } public void run () { try { int c = 0; while ( ( c = System.in.read()) > -1 ) { this.out.write(c); } } catch ( IOException e ) { e.printStackTrace(); System.exit(-1); } } } public static void main ( String[] args ) { try { (new TwoWaySerialComm()).connect("COM3"); } catch ( Exception e ) { e.printStackTrace(); } } } From lfarkas at lfarkas.org Tue Aug 19 07:32:59 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Tue, 19 Aug 2008 15:32:59 +0200 Subject: [Rxtx] JNI or CNI Message-ID: <48AACB8B.9060606@lfarkas.org> hi, what is the current recommended way to rxtx on linux JNI or it's better to use CNI? is the CNI version fully functional and the same level as the JNI? i currently try to make a rhel/centos/fedora rpm for rxtx but has many problems with the standard dir structure. yours. -- Levente "Si vis pacem para bellum!" From lfarkas at lfarkas.org Tue Aug 19 08:47:34 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Tue, 19 Aug 2008 16:47:34 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel Message-ID: <48AADD06.7040809@lfarkas.org> hi, newer or not so newer linux kernel do not contain the UTS_RELEASE so the current rxtx is not compile on the latest kernels. even if it's commented out in the cvs configure there are other places. i attcahed a patch which fix it (or at least doesn't cause error at non-debug build). ps. is there any plan to the new 2.1-8 release in the near future? there are many changes (at least the license change in all file and in this case create a diff is very difficult)? the latest release more then 2 years old:-( -- Levente "Si vis pacem para bellum!" -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-2.1-uts.patch Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080819/ab5d38ac/attachment.pl From ajmas at sympatico.ca Tue Aug 19 16:21:53 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 19 Aug 2008 18:21:53 -0400 Subject: [Rxtx] Event based example Message-ID: <24735BFB-B088-4B84-8173-FE98DF63B12F@sympatico.ca> Hi, I have just posted an example of using SerialPortEventListener in the Wiki: http://rxtx.qbang.org/wiki/index.php/Event_Based_Two_Way_Communication If you see any issues please could you let me know, or makes the changes. Andre From rick_knight at rlknight.com Mon Aug 4 13:25:10 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Mon, 04 Aug 2008 12:25:10 -0700 Subject: [Rxtx] Sun's Comm API? Message-ID: <48975796.4010600@rlknight.com> I have an application that requires the javax compatible version of RXTX and Sun's comm api. I've been able to download and extract the version of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api anywhere. Can someone tell me where I can find it? Or maybe send me a copy? Also, when I try to build RXTX, configure and make complete successfully but make install failes with this error libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 I've never come accross this error before. How can I get past it? Thanks, Rick From bboyes at systronix.com Mon Aug 4 19:10:01 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:10:01 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48975796.4010600@rlknight.com> References: <48975796.4010600@rlknight.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/cb9c6167/attachment-0017.html From bboyes at systronix.com Mon Aug 4 19:12:37 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:12:37 -0600 Subject: [Rxtx] Towards an RXTX release - CSR BT/USB chipset In-Reply-To: <488FB7E7.8000802@gmail.com> References: <460801A4097E3D4CA04CC64EE648584806C56CF0@ism-mail03.corp.ad.wrs.com> <13557-75390@sneakemail.com> <20980-23424@sneakemail.com> <488FB7E7.8000802@gmail.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/52236088/attachment-0017.html From tjarvi at qbang.org Mon Aug 4 19:42:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 19:42:21 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: On Mon, 4 Aug 2008, Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: > I have an application that requires the javax compatible > version of RXTX > and Sun's comm api. I've been able to download and extract > the version > of RXTX that I need (2.0-7pre2) but I can't find Sun's camm > api > anywhere. Can someone tell me where I can find it? Or maybe > send me a > > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm port > support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have just > a ZIP with only the .class JAR file - no source or docs), has a readme > with these comments: > > This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release.? The 2.0.3 release itself is > no longer distributed.? comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project.? The RxTx project (http://www.rxtx.org ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org) was opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support.? Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins.? Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > ? > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > I hope that is helpful! > It would be nice to work with Sun to resolve those longstanding issues. But it may not be practical unless the process goes as fast and painless as the grandfathering of commapi did. Another option may be the old kaffe extensions that moved to gnu classpathx. These don't have the native libraries but should provide the 2.0 interface and the javax.comm.properties mechansim for SPI. http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Mon Aug 4 20:23:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Mon, 04 Aug 2008 20:23:57 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4897B9BD.5070809@ergotech.com> Has there been any work/would it be possible, to layer a javacomm look-alike on top of the GNU code? The goal is not to move the javax code forward, but to emulate the "legacy" javax packages for people who still need this. Jim Trent Jarvi wrote: > On Mon, 4 Aug 2008, Bruce Boyes wrote: > >> At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible >> version of RXTX >> and Sun's comm api. I've been able to download and extract >> the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm >> api >> anywhere. Can someone tell me where I can find it? Or maybe >> send me a >> >> >> javaxcomm has had a sort of on-again off-again history. The windoze >> version has been languishing for years (literally) but there are newer >> versions for other OS's. >> >> We try to keep links on one of our help pages current: >> http://www.practicalembeddedjava.com/tools/javatools_list.html >> which gets you to here: >> http://java.sun.com/products/javacomm/ >> where it says in fact they no longer even support Windows and Mac: >> "Implementations of the API are currently available for Solaris SPARC, >> Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so >> someone could support it. But I guess that's part of the reason RXTX >> exists! >> >> So one of Sun's own products, SunSPOT, has to use RXTX to get comm port >> support. >> >> The version we use is 2.0 from 11/15/1998. I have posted it on our >> website, which is within the terms of the license agreement contained >> therein (as I understand it). >> >> The last version of javaxcomm for Windows, 2.0.3, (for which I have just >> a ZIP with only the .class JAR file - no source or docs), has a readme >> with these comments: >> >> This distribution contains the comm.jar file original part >> of the COMMAPI 2.0.3 release. The 2.0.3 release itself is >> no longer distributed. comm.jar, which contains the comm >> API java class files (eg. Sun's binary implementation of the >> interface classes), is being made available, unsupported, >> with no obligation to fix bugs, at the request of the RXTX >> project. The RxTx project (http://www.rxtx.org ), uses the >> comm.jar class files, but provides their own native library >> components to provide support for other platforms. >> >> The 2.0.3 comm.jar is being provided in this way because >> as of COMMAPI 3.x, the java binary implementation forked and >> became incompatible with the RxTx project's native code. >> Due to the lack of a clear business case, and to resource >> constraints, no additional resources are being >> provided to provide an alternative engineering solution >> at the time of writing. >> >> RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: >> >> Ultimately the COMMAPI would be better served if a Java >> Community Process JSR (http://www.jcp.org) was opened and >> the COMMAPI was rearchitected to provide a more pluggable >> framework to improve cross-platform support. Such an >> architecture would embody a better defined and better >> documented SPI interface, including a way for comm. ports >> to be revealed to the client application through the API >> via platform-aware plugins. Similarly, native code used >> to access comm port in general could be handled more >> flexibly using a plugin model, whereby on any platform, >> multiple native modules could be in use simultaneously. >> >> Since there are now various ways serial ports can be implemented >> and accessed, modular comm. port JNI native libraries would be >> of benefit insofar as removing the burden of over-generalization >> from any single native component, or inversely, by relieving the >> implicit constraint that comm. drivers be accessed only via a >> monolithic mechanism, such as the UNIX vnode interface. >> >> paul.klissner at sun.com >> 6/10/06 >> >> I hope that is helpful! >> > > It would be nice to work with Sun to resolve those longstanding issues. > But it may not be practical unless the process goes as fast and painless > as the grandfathering of commapi did. > > Another option may be the old kaffe extensions that moved to gnu > classpathx. These don't have the native libraries but should provide > the 2.0 interface and the javax.comm.properties mechansim for SPI. > > http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Mon Aug 4 21:09:15 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 21:09:15 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? Message-ID: Hi Jim, I will not step into the javax.comm namespace without Sun's explicite permission. I fully understand the pain point you are trying to address. In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm Linux) - which remains an integral part of rxtx. At the time it was a win for Sun and rxtx. The Sun commapi license is/was fairly clear that rxtx should not step into that namespace. It made sense as Sun was active in that space and rxtx may go into another namespace - it was an experiment in working with Sun. This may sound silly looking at something that happened almost 10 years ago. In a community of respect which Sun helped create, there is no question about what to do. I hope eventually Sun will step up and do a right thing too. I agree that this is hurting the API more than helping it. There are also questions about how to replace the API in the long term which includes HID support which isn't going well so far. Others that can't even look at Sun's javax.comm today and can look at Kaffe's contribution to classpathx can easily work around such restrictions. On Mon, 4 Aug 2008, Jim Redman wrote: > Has there been any work/would it be possible, to layer a javacomm > look-alike on top of the GNU code? > > The goal is not to move the javax code forward, but to emulate the > "legacy" javax packages for people who still need this. > > Jim > > Trent Jarvi wrote: >> >> It would be nice to work with Sun to resolve those longstanding issues. >> But it may not be practical unless the process goes as fast and painless >> as the grandfathering of commapi did. >> >> Another option may be the old kaffe extensions that moved to gnu >> classpathx. These don't have the native libraries but should provide >> the 2.0 interface and the javax.comm.properties mechansim for SPI. >> >> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From florianmanschwetus at gmx.de Tue Aug 5 05:04:46 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 13:04:46 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: References: <48971C1F.9020806@gmx.de> Message-ID: <489833CE.1040801@gmx.de> Just look at sendCommand in this method I have to place a Thread.sleep(20) after each byte send to get working. Even the event based receive doesn't work fine but this could be may stupidness. The specifikation document (it is on the last pages of the manual) for the beamer could be found on: http://www.optoma.co.uk/support.aspx Florian Manschwetus Trent Jarvi schrieb: > > Hi Florian > > Sorry for the top post in advance. I worry you may not see my answer > under all your code :) > > I have not received this email before. This is 500k of code which I > don't have time to read. I can spend about 5 min on each hobby email > and still get to work in the morning. I have a couple suggestions for > how to get an answer. > > First, cut out your comments and extra code so you can demonstrate the > question (I might even glance and see what is wrong then). Don't go for > a working final product. Isolate the problem using a simple program and > then ask with that as an example. If I did what you just did, I'd have > to post 3/4 of a million lines of code :) > > Second, join the rxtx mail-list and ask there. This will give you 100x > more eyes. I'll also read and try to follow. > > -- > taj > > > > On Mon, 4 Aug 2008, Florian Manschwetus wrote: > >> It could be that my university account is blocked by filters so >> resending from here. >> >> >> Topic is to control Optoma HD80 beamer using rs232 serial chat. >> This code is able to detect power state and switch the beamer on / off. >> connected is the beamer using a digitus usb 2.0 serial adapter with an >> FT232 USB-Serial adapter the systems architecture is amd64. >> >> Please take a look in the sendCommand routine i have to place theire >> those Thread.sleep to get it working. >> Now the question is this correct or is there a better way to get this >> working correctly? >> >> In the javadoc coming with the install i found this: >> setBaudBase >> >> public boolean setBaudBase(int BaudBase) >> throws UnsupportedCommOperationException, >> java.io.IOException >> >> Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 >> before using. >> >> could this explain the error? >> I attached my java source and the protocol description for the beamer >> (available on vendor website). >> >> thx, >> Florian Manschwetus >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: TestRS232.java Type: text/x-java Size: 9143 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0034.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0035.bin From michael.erskine at ketech.com Tue Aug 5 05:53:49 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Tue, 5 Aug 2008 12:53:49 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489833CE.1040801@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> > Just look at sendCommand in this method I have to place a > Thread.sleep(20) after each byte send to get working. Even the event > based receive doesn't work fine but this could be may stupidness. Hi Florian, Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. Regards, Michael Erskine. From florianmanschwetus at gmx.de Tue Aug 5 07:28:15 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:28:15 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> Message-ID: <4898556F.8000208@gmx.de> Michael Erskine schrieb: >> Just look at sendCommand in this method I have to place a >> Thread.sleep(20) after each byte send to get working. Even the event >> based receive doesn't work fine but this could be may stupidness. > > Hi Florian, > > Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. > > Regards, > Michael Erskine. > Ok, sounds fine for the receiving problem. But why i have to wait after each byte when sending a command squence? (the for loop in send command) Florian > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/284f350c/attachment-0016.bin From florianmanschwetus at gmx.de Tue Aug 5 07:44:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:44:14 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <4898592E.2020908@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >>> Just look at sendCommand in this method I have to place a >>> Thread.sleep(20) after each byte send to get working. Even the event >>> based receive doesn't work fine but this could be may stupidness. >> >> Hi Florian, >> >> Yes, naturally you'll have to wait for a response from the other end. >> Why not wait for notification from the event thread perhaps using a >> BlockingDeque rather than your LinkedList. Generally I >> try to decouple all input and output streams: in your case your >> application is operating synchronously like the "expect" program >> (http://expect.nist.gov/) so waits (or timeouts) will need to be >> factored in. >> >> Regards, >> Michael Erskine. >> > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) > > Florian Furthermore there is this basic baud with this confusing javadoc entry: public boolean setBaudBase(int BaudBase) throws UnsupportedCommOperationException, java.io.IOException Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 before using. maybe this could explain something Florian >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/006c7425/attachment-0016.bin From jredman at ergotech.com Tue Aug 5 09:13:36 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 05 Aug 2008 09:13:36 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: Message-ID: <48986E20.3060104@ergotech.com> Trent, So two issues: 1) Technically I'm still not sure how easy/practical a layer would be. The problems are always classes like listeners, and wrapping returns of gnu.io classes. I really see it as a "delegate" type of concept. Any thoughts or ideas of the practicality of this approach? The idea is not to modify RXTX. 2) Javax. The javax namespace does seem to be in widespread use outside of Sun (the same is true for the java namespace). The classpath extensions, or some other location, should be interested in a JavaComm implementation even if it does have dependencies on RXTX. Would you have any philosophical objection to an approach like that? Of course, I suspect it might be better if someone with that authority at Sun would admit that the javax namespace is already in the wild and that there is no problem with it being used within RXTX. Jim Trent Jarvi wrote: > Hi Jim, > > I will not step into the javax.comm namespace without Sun's explicite > permission. I fully understand the pain point you are trying to address. > > In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm > Linux) - which remains an integral part of rxtx. At the time it was a win for > Sun and rxtx. > > The Sun commapi license is/was fairly clear that rxtx should not step into that > namespace. It made sense as Sun was active in that space and rxtx may go into > another namespace - it was an experiment in working with Sun. > > This may sound silly looking at something that happened almost 10 years ago. > In a community of respect which Sun helped create, there is no question about > what to do. I hope eventually Sun will step up and do a right thing too. > > I agree that this is hurting the API more than helping it. There are also > questions about how to replace the API in the long term which includes HID > support which isn't going well so far. > > Others that can't even look at Sun's javax.comm today and can look at Kaffe's > contribution to classpathx can easily work around such restrictions. > > On Mon, 4 Aug 2008, Jim Redman wrote: > >> Has there been any work/would it be possible, to layer a javacomm >> look-alike on top of the GNU code? >> >> The goal is not to move the javax code forward, but to emulate the >> "legacy" javax packages for people who still need this. >> >> Jim >> >> Trent Jarvi wrote: >>> It would be nice to work with Sun to resolve those longstanding issues. >>> But it may not be practical unless the process goes as fast and painless >>> as the grandfathering of commapi did. >>> >>> Another option may be the old kaffe extensions that moved to gnu >>> classpathx. These don't have the native libraries but should provide >>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>> >>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From sandeep at genevasoftech.com Tue Aug 5 11:18:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Tue, 05 Aug 2008 22:48:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <48988B6C.5080409@genevasoftech.com> Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. *-- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/ad20f1cb/attachment-0016.html From Martin.Oberhuber at windriver.com Tue Aug 5 13:30:17 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Tue, 5 Aug 2008 21:30:17 +0200 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Sandeep, shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on Sol7 but I've successfully run it on Sol9 and Sol10. Or is your request really about a native 64bit variant? I'm afraid that then you're out of luck since I think that quite a bit of RXTX is not yet ready for 64 bit. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Sandeep Kumar K Sent: Tuesday, August 05, 2008 7:19 PM To: rxtx at qbang.org Subject: [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so for Solaris 9 Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. -- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/81b7f988/attachment-0016.html From tjarvi at qbang.org Tue Aug 5 22:38:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 22:38:34 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 5 Aug 2008, Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built > on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid that > then > you're out of luck since I think that quite a bit of RXTX is not yet > ready > for 64 bit. > While rxtx-2.1-7 probably has problems, The CVS code should be OK for 64 bit Solaris. If it isn't, let me know and I'll find which patch is missing. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Aug 5 23:13:00 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 23:13:00 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48986E20.3060104@ergotech.com> References: <48986E20.3060104@ergotech.com> Message-ID: On Tue, 5 Aug 2008, Jim Redman wrote: > Trent, > > So two issues: > > 1) Technically I'm still not sure how easy/practical a layer would be. The > problems are always classes like listeners, and wrapping returns of gnu.io > classes. I really see it as a "delegate" type of concept. Any thoughts or > ideas of the practicality of this approach? The idea is not to modify RXTX. I have not put too much thought into this. I assume you want what rxtx 2.0 provided to tie into javax.comm implementations. More classes could be added to rxtx 2.1-7 for SPI support. Maintaining rxtx-2.0 could also be handed to someone if they like. > > 2) Javax. The javax namespace does seem to be in widespread use outside of > Sun (the same is true for the java namespace). The classpath extensions, or > some other location, should be interested in a JavaComm implementation even > if it does have dependencies on RXTX. Would you have any philosophical > objection to an approach like that? > No problems. Classpathx would be a possible place to do it. I'd suggest thinking twice about what this involves in practical terms. You would be wanting to revive the 2.0 API while Sun is at 3.0 and grandfathering the JSR. This undermines the main reason (established api) for using the javax.comm namespace and does not leave such a project in a good position. The only win I see here is maintaining support for applications that can't migrate namespaces. Not that that isn't important. At some point it is going to be less work to just edit the bytecode :) Such a javax.comm effort would also be signing up new projects that decided to use the work up for concerns they probably will not understand or expect. That probably isn't a good path to facilitate for new projects at this time. We will put a good faith effort to work well with others but keep in mind the project has limited bandwidth for such efforts. > Of course, I suspect it might be better if someone with that authority at Sun > would admit that the javax namespace is already in the wild and that there is > no problem with it being used within RXTX. > > Jim > > Trent Jarvi wrote: >> Hi Jim, >> >> I will not step into the javax.comm namespace without Sun's explicite >> permission. I fully understand the pain point you are trying to address. >> >> In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java >> Comm Linux) - which remains an integral part of rxtx. At the time it was a >> win for Sun and rxtx. >> >> The Sun commapi license is/was fairly clear that rxtx should not step into >> that namespace. It made sense as Sun was active in that space and rxtx may >> go into another namespace - it was an experiment in working with Sun. >> >> This may sound silly looking at something that happened almost 10 years >> ago. In a community of respect which Sun helped create, there is no >> question about what to do. I hope eventually Sun will step up and do a >> right thing too. >> >> I agree that this is hurting the API more than helping it. There are also >> questions about how to replace the API in the long term which includes HID >> support which isn't going well so far. >> >> Others that can't even look at Sun's javax.comm today and can look at >> Kaffe's contribution to classpathx can easily work around such >> restrictions. >> >> On Mon, 4 Aug 2008, Jim Redman wrote: >> >>> Has there been any work/would it be possible, to layer a javacomm >>> look-alike on top of the GNU code? >>> >>> The goal is not to move the javax code forward, but to emulate the >>> "legacy" javax packages for people who still need this. >>> >>> Jim >>> >>> Trent Jarvi wrote: >>>> It would be nice to work with Sun to resolve those longstanding issues. >>>> But it may not be practical unless the process goes as fast and painless >>>> as the grandfathering of commapi did. >>>> >>>> Another option may be the old kaffe extensions that moved to gnu >>>> classpathx. These don't have the native libraries but should provide >>>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>>> >>>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From sandeep at genevasoftech.com Wed Aug 6 00:03:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Wed, 06 Aug 2008 11:33:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: <48993EB8.30107@genevasoftech.com> Thank you Mr. Martin for your suggestion. The native file which is given in rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am getting the following error . Any suggestions to solve this issue. I am using Solaris SPARC 64 bit machine. ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) thrown while loading gnu.io.RXTXCommDriver Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(Unknown Source) at java.lang.ClassLoader.loadLibrary(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) at com.ReadFromModem.main(ReadFromModem.java:84) * * *Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid > that then > you're out of luck since I think that quite a bit of RXTX is not yet ready > for 64 bit. > > Cheers, > -- > *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > ------------------------------------------------------------------------ > *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On > Behalf Of *Sandeep Kumar K > *Sent:* Tuesday, August 05, 2008 7:19 PM > *To:* rxtx at qbang.org > *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so > for Solaris 9 > > Hi, > > Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 > bit machine. The librxtxSerial.so given in website is for Solaris 8. > > *-- > > Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/1e920343/attachment-0016.html From tjarvi at qbang.org Wed Aug 6 00:21:42 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 00:21:42 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <48993EB8.30107@genevasoftech.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> <48993EB8.30107@genevasoftech.com> Message-ID: Hi Sandeep You may be out of luck unless you can compile the 2.1 src in CVS (requires gnu make and gcc). But you could try the ToyBox(R)(TM) which is a collection of WiLdLy untested cross compiled 2.1-7 binaries covering everything from the ibm z series to embeded arm/ppc. To give an idea how poorly these are tested, I don't even know if z series machines have a serial port. ftp://www.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Solaris They should at least match the binary types. Actually, I think if you use the rxtx jar from CVS with that file, it should 'work' as the fix for 64 bits was in java not the native code. You could just cd rxtx*/src; javac *.java then jar -cf RXTXcomm.jar `find -name \*.class` to create the hybrid which will complain about version information a bit. On Wed, 6 Aug 2008, Sandeep Kumar K wrote: > Thank you Mr. Martin for your suggestion. The native file which is given in > rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am > getting the following error . > Any suggestions to solve this issue. > I am using Solaris SPARC 64 bit machine. > > ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar > java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 > (Possible cause: architecture word > width mismatch) thrown while loading gnu.io.RXTXCommDriver > Exception in thread "main" java.lang.UnsatisfiedLinkError: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF > class: ELFCLASS64 (Possible cause: > architecture word width mismatch) > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(Unknown Source) > at java.lang.ClassLoader.loadLibrary(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > at com.ReadFromModem.main(ReadFromModem.java:84) > > * > * > > *Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > > > Oberhuber, Martin wrote: >> Sandeep, >> shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse >> variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on >> Sol7 but I've successfully run it on Sol9 and Sol10. >> Or is your request really about a native 64bit variant? I'm afraid that >> then >> you're out of luck since I think that quite a bit of RXTX is not yet ready >> for 64 bit. >> Cheers, >> -- >> *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> ------------------------------------------------------------------------ >> *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On >> Behalf Of *Sandeep Kumar K >> *Sent:* Tuesday, August 05, 2008 7:19 PM >> *To:* rxtx at qbang.org >> *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so >> for Solaris 9 >> >> Hi, >> >> Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 >> bit machine. The librxtxSerial.so given in website is for Solaris 8. >> >> *-- >> Thanks & Regards >> >> Sandeep Kumar K >> Sr. Software Engineer >> Geneva Software Technologies >> Whitefield, Bangalore >> Mob : 9880193454* >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> From michael.erskine at ketech.com Wed Aug 6 01:39:28 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 6 Aug 2008 08:39:28 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Florian Manschwetus wrote: > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) Hi Florian, I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. Regards, Michael Erskine. From florianmanschwetus at gmx.de Wed Aug 6 02:53:16 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 06 Aug 2008 10:53:16 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Message-ID: <4899667C.6010706@gmx.de> Michael Erskine schrieb: > Florian Manschwetus wrote: >> Ok, sounds fine for the receiving problem. >> But why i have to wait after each byte when sending a command squence? >> (the for loop in send command) > > Hi Florian, > I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. > > Regards, > Michael Erskine. > correct with a terminal on the other end it works, my idea was that this basic baud has some influence. Could some one explain what it is for? Florian > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/c2b4fa84/attachment-0016.bin From rick_knight at rlknight.com Wed Aug 6 13:01:07 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:01:07 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F4F3.3020707@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > I have an application (Readerware) that uses RXTX with Javax to access the serial port. This used to work fine under previous Linux' and Java, but something has changed, I assume with Java itself , that is causing the application to fail with a link error. The application is not able to find librxtxSerialParallel.so. RXTX supplies librxtxSerial.so and librxtxParallel.so, but not librxtxSerialParallel.so. Where can I get librxtxSerialParallel.so, or do I need it? Is something else causing the lib to not be found? Thanks, Rick Knight From rick_knight at rlknight.com Wed Aug 6 13:17:55 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:17:55 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F8E3.5060400@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Thanks for the reply. The developer of the app I'm trying to use (Readerware) has sent me a copy of the comm.api and I've copied the library (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar into the proper places. When I try to run the application, I get this error... Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: /usr/lib/libSolarisSerialParallel.so: /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not little-endian (Possible cause: endianness mismatch) Caught java.lang.UnsatisfiedLinkError: com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I while loading driver com.sun.comm.SolarisDriver Is there a way around this error? Thanks again, Rick Knight From jlar310 at gmail.com Wed Aug 6 13:37:42 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 14:37:42 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899F8E3.5060400@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > The developer of the app I'm trying to use (Readerware) has sent me a > copy of the comm.api and I've copied the library > (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar > into the proper places. When I try to run the application, I get this > error... > > Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: > /usr/lib/libSolarisSerialParallel.so: > /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not > little-endian (Possible cause: endianness mismatch) > Caught java.lang.UnsatisfiedLinkError: > com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I > > while loading driver com.sun.comm.SolarisDriver > > Is there a way around this error? What host OS are you running? From your original post it looks like 32 bit Linux. The libSolarisSerialParallel.so file is for Sun Solaris and will vary depending on the underlying hardware architecture as well. Sorry for the double post Rick, but I failed to send this to the list the first time... -- Jeff From rick_knight at rlknight.com Wed Aug 6 13:44:29 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:44:29 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: <4899FF1D.9030504@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > > >> The developer of the app I'm trying to use (Readerware) has sent me a >> copy of the comm.api and I've copied the library >> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >> into the proper places. When I try to run the application, I get this >> error... >> >> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >> /usr/lib/libSolarisSerialParallel.so: >> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >> little-endian (Possible cause: endianness mismatch) >> Caught java.lang.UnsatisfiedLinkError: >> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >> >> while loading driver com.sun.comm.SolarisDriver >> >> Is there a way around this error? >> > > What host OS are you running? From your original post it looks like 32 > bit Linux. > > The libSolarisSerialParallel.so file is for Sun Solaris and will vary > depending on the underlying hardware architecture as well. > > I'm running Kubuntu Linux (debian based). It's 32 bit. Rick Knight From jlar310 at gmail.com Wed Aug 6 15:33:23 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 16:33:23 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > I don't think Sun did binary libraries for Linux in the 2.0 version. Can someone with more historical experience than I confirm that? I recently tried to port a Comm API application from Solaris sparc to Linux x86 and likewise could not get my hands on the binary libraries. I eventually just re-wrote the code to use the gnu namespace packages and rxtx 2.1. What I don't understand is why your application vendor does not provide everything you need to run their software. FYI: I have librxtxParallel.so and librxtxSerial.so installed at JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is /usr/java/default which is actually a softlink to /usr/java/jre1.6.0_05. -- Jeff From defiantlew at yahoo.com.au Wed Aug 6 16:29:33 2008 From: defiantlew at yahoo.com.au (Lew L) Date: Thu, 7 Aug 2008 08:29:33 +1000 Subject: [Rxtx] Sun's Comm API Documentation References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> Message-ID: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> As a matter of interest is the Sun Comm API documentation available somewhere? I have tried the Sun site but it seems to have been removed. Unless I have missed the documentation for RXTX? I javadocced the RXTX source but information (to me) is minimal. Somewhere I got the impression that the Sun Comm API docs is, or was, compatible with RXTX, what is the best docs to use in conjuntion with RXTX and where may the be available? Cheers Lew From rick_knight at rlknight.com Wed Aug 6 17:18:33 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:18:33 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A3149.4050306@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff I'm not sure if I posted this here or not, but when I try to build RXTX from source I get this install error... make all-am make[1]: Entering directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' make[1]: Nothing to be done for `all-am'. make[1]: Leaving directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 Can you tell me how to get past this error and get RXTX built and installed? Thanks, Rick From bboyes at systronix.com Wed Aug 6 17:40:12 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Wed, 06 Aug 2008 17:40:12 -0600 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: At 16:29 08/06/2008, Lew L wrote: >As a matter of interest is the Sun Comm API documentation available >somewhere? I have tried the Sun site but it seems to have been removed. It's in the file we have posted, link in prev email (sorry, in a huge hurry right now). Javadocs definitely there. >Unless I have missed the documentation for RXTX? I javadocced the RXTX >source but information (to me) is minimal. >Somewhere I got the impression that the Sun Comm API docs is, or was, >compatible with RXTX, what is the best docs to use in conjuntion with RXTX >and where may the be available? Yeah, this is one of my concerns/beefs. There is little documentation for RXTX and it isn't just the same as javaxcomm. I would be willing to help out writing docs for RXTX! Yes really... esp if we can fix the Bluetooth issues. best regards Bruce >Cheers >Lew > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx ------- WWW.SYSTRONIX.COM ---------- Real embedded Java and much more +1-801-534-1017 Salt Lake City, USA From rick_knight at rlknight.com Wed Aug 6 17:54:08 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:54:08 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A39A0.2090309@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff, I would like for my vendor to switch to rxtx 2.1. It would make things much easier for me. I'm not sure why he's still using the javax compatible code. He's a small operation. Re-writing the code to use gnu namespace sounds like a major overhaul. Was it? Thanks, Rick From tjarvi at qbang.org Wed Aug 6 21:35:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:35:12 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: >> >>> Jeff wrote: >>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>>> >>>> >>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things > much easier for me. I'm not sure why he's still using the javax > compatible code. He's a small operation. Re-writing the code to use gnu > namespace sounds like a major overhaul. Was it? > Hi Jeff, The changes are fairly mechanical. Imports need to change and any explicite use of the namespace needs to change such as catching an exception. The following script was made for maintaining rxtx 2.0 but can apply to other needs. It is in the contrib dir with rxtx source. #!/bin/sh # Don't use! :) # # Sat, 03 May 2003 16:45:08 Modifications from J?rg Weule # Create a ed-cmd for the change of one pattern # case $1 in gnu) X=g/javax_comm/s+javax_comm+gnu_io+g ;; javax) X=g/gnu_io/s+gnu_io+javax_comm+g ;; *) echo;echo;echo From the top rxtx directory run;echo;echo -e \\t./ChangePackage.sh gnu;echo -e \\t\\tor;echo -e \\t./ChangePackage.sh javax;echo;echo; exit 0 ;; esac # # ed will be used to keep the owner and mode of the files unchanged. # We have run the ed-script for the characters '.' '/' as well. # "tr _ $D" do the change. # find . -type f -a -print | grep -v $0 | (while read F ; do ( echo $X; echo $X| tr _ /; echo $X| tr _ .; echo w; echo q ) | ed $F 2>&1 >/dev/null done ) # # Now we do little changes at the Makefiles. Hope that all we need. # find . -name Makefile\* -a -print | (while read F ; do cat < References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: On Thu, 7 Aug 2008, Lew L wrote: > As a matter of interest is the Sun Comm API documentation available > somewhere? I have tried the Sun site but it seems to have been removed. > > Unless I have missed the documentation for RXTX? I javadocced the RXTX > source but information (to me) is minimal. > Somewhere I got the impression that the Sun Comm API docs is, or was, > compatible with RXTX, what is the best docs to use in conjuntion with RXTX > and where may the be available? > Hi Lew, The documentation on Sun's website is accurate. The changes that are problematic in 3.0 are on the backside which rxtx used to plug into. http://java.sun.com/products/javacomm/reference/api/index.html CommPortIdentifier may have some minor differences (judging by the authors notes). -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Aug 6 21:46:08 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:46:08 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > If javax.comm.properties is properly installed and you are using a 2.0 version of Sun's commapi with rxtx 2.0, you should not see the library attempt to load libSolarisSerialParallel.so. Sun CommAPI 3.0 will not work with any version of rxtx as it is hard coded to use the shared library. See the INSTALL file with rxtx-2.0 source for more help with the properties file. -- Trent Jarvi tjarvi at qbang.org From jlar310 at gmail.com Thu Aug 7 06:32:06 2008 From: jlar310 at gmail.com (Jeff) Date: Thu, 7 Aug 2008 07:32:06 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > Jeff wrote: >> >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >> wrote: >> >>> >>> Jeff wrote: >>> >>>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>> wrote: >>>> >>>> >>>> >>>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things much > easier for me. I'm not sure why he's still using the javax compatible code. > He's a small operation. Re-writing the code to use gnu namespace sounds like > a major overhaul. Was it? I found it quite easy. In fact, in order to accommodate the transition, I actually separated all of the code that deals directly with the Comm API or RXTX into a helper class. The helper class was then coded to use reflection to determine which library was available and then instantiate the necessary objects. No direct imports of either library are used. The main application just needs to get it's hands on the IO streams and need not deal directly with the libraries. Other programs may not be so simple... But this doesn't really help you unless your vendor forks over the source code... -- Jeff From rick_knight at rlknight.com Thu Aug 7 09:47:12 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Thu, 07 Aug 2008 08:47:12 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: <489B1900.10108@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >>> wrote: >>> >>> >>>> Jeff wrote: >>>> >>>> >>>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>>> copy of the comm.api and I've copied the library >>>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>>> into the proper places. When I try to run the application, I get this >>>>>> error... >>>>>> >>>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>>> /usr/lib/libSolarisSerialParallel.so: >>>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>>> little-endian (Possible cause: endianness mismatch) >>>>>> Caught java.lang.UnsatisfiedLinkError: >>>>>> >>>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>>> >>>>>> while loading driver com.sun.comm.SolarisDriver >>>>>> >>>>>> Is there a way around this error? >>>>>> >>>>>> >>>>>> >>>>> What host OS are you running? From your original post it looks like 32 >>>>> bit Linux. >>>>> >>>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>>> depending on the underlying hardware architecture as well. >>>>> >>>>> >>>>> >>>>> >>>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>>> >>>> >>>> >>> I don't think Sun did binary libraries for Linux in the 2.0 version. >>> Can someone with more historical experience than I confirm that? >>> >>> I recently tried to port a Comm API application from Solaris sparc to >>> Linux x86 and likewise could not get my hands on the binary libraries. >>> I eventually just re-wrote the code to use the gnu namespace packages >>> and rxtx 2.1. >>> >>> What I don't understand is why your application vendor does not >>> provide everything you need to run their software. >>> >>> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >>> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >>> /usr/java/default which is actually a softlink to >>> /usr/java/jre1.6.0_05. >>> >>> >>> >> Jeff, >> >> I would like for my vendor to switch to rxtx 2.1. It would make things much >> easier for me. I'm not sure why he's still using the javax compatible code. >> He's a small operation. Re-writing the code to use gnu namespace sounds like >> a major overhaul. Was it? >> > > I found it quite easy. In fact, in order to accommodate the > transition, I actually separated all of the code that deals directly > with the Comm API or RXTX into a helper class. The helper class was > then coded to use reflection to determine which library was available > and then instantiate the necessary objects. No direct imports of > either library are used. The main application just needs to get it's > hands on the IO streams and need not deal directly with the libraries. > Other programs may not be so simple... > > But this doesn't really help you unless your vendor forks over the > source code... > > Jeff, This may not help me directly, but I'm going to forward this thread to the vendor. I think he'll be open to making things work. Thanks again, Rick Knight From agusmunioz at gmail.com Thu Aug 7 16:39:51 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Thu, 7 Aug 2008 19:39:51 -0300 Subject: [Rxtx] How to send ack? Message-ID: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Hi, I'm still learning about serial communication and I have some doubts. I've got this question about how to do the following thing in rxtx. I have this hardware that connect to a PC using a serial port. These hardware receives data from a telephone line, proccess it, and then send it forward to the serial port. I've used a program named wincomm that shows what information is send it through the serial port and I have the nex behaviour: The hardware has a buffer where all data is stored, that cannot be sent it through the seria port. The program reads the first data send it by the hardware, and keep reading the same data always. There is a button in the application that says enable Ack, and when I click, then the hardware start to send all the stored information, and all the information is shown. I write a class, using rxtx that reads the serial port, and the same thing happens, it remains reading the same (first) data all the time. And I thing something like the enable Ack I'm missing. How can I do this enable Ack from my java code using rxtx? Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080807/e0a0f9a1/attachment-0014.html From ajmas at sympatico.ca Thu Aug 7 18:26:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 7 Aug 2008 20:26:41 -0400 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: <4BF42297-81E2-4BB8-A89F-1D43588379AE@sympatico.ca> On 6-Aug-08, at 19:40 , Bruce Boyes wrote: >> Unless I have missed the documentation for RXTX? I javadocced the >> RXTX >> source but information (to me) is minimal. >> Somewhere I got the impression that the Sun Comm API docs is, or was, >> compatible with RXTX, what is the best docs to use in conjuntion >> with RXTX >> and where may the be available? > > Yeah, this is one of my concerns/beefs. There is little documentation > for RXTX and it isn't just the same as javaxcomm. > > I would be willing to help out writing docs for RXTX! Yes really... > esp if we can fix the Bluetooth issues. If you want to contribute documentation then the best place to do that is the wiki. If there is anything missing or that could be improved on then please do so. If there are any points that you would like to see improved, for which you don't have the knowledge then ask on the mailing list for a volunteer. Andre From florianmanschwetus at gmx.de Fri Aug 8 03:04:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Fri, 08 Aug 2008 11:04:14 +0200 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Message-ID: <489C0C0E.2020401@gmx.de> Agustin Mu?oz schrieb: > Hi, I'm still learning about serial communication and I have some > doubts. I've got this question about how to do the following thing in rxtx. > I have this hardware that connect to a PC using a serial port. These > hardware receives data from a telephone line, proccess it, and then send > it forward to the serial port. I've used a program named wincomm that > shows what information is send it through the serial port and I have the > nex behaviour: > > The hardware has a buffer where all data is stored, that cannot be sent > it through the seria port. > The program reads the first data send it by the hardware, and keep > reading the same data always. > There is a button in the application that says enable Ack, and when I > click, then the hardware start to send all the stored information, and > all the information is shown. > > I write a class, using rxtx that reads the serial port, and the same > thing happens, it remains reading the same (first) data all the time. > And I thing something like the enable Ack I'm missing. > How can I do this enable Ack from my java code using rxtx? Afaik, a look at man ascii reveals: Okt Dez Hex Char 006 6 06 ACK So, i hope this will do the job: send(6); florian > > Thanks in advance > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/5b4965f8/attachment-0014.bin From agusmunioz at gmail.com Fri Aug 8 16:31:00 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 19:31:00 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <489C0C0E.2020401@gmx.de> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> Message-ID: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Hi Florian, thanks for the answer. By send(6) you mean to get the port OutputStream and write a 6? I try that but it didn't work. Any suggestion? Thanks On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < florianmanschwetus at gmx.de> wrote: > Agustin Mu?oz schrieb: > > Hi, I'm still learning about serial communication and I have some doubts. >> I've got this question about how to do the following thing in rxtx. >> I have this hardware that connect to a PC using a serial port. These >> hardware receives data from a telephone line, proccess it, and then send it >> forward to the serial port. I've used a program named wincomm that shows >> what information is send it through the serial port and I have the nex >> behaviour: >> >> The hardware has a buffer where all data is stored, that cannot be sent >> it through the seria port. >> The program reads the first data send it by the hardware, and keep reading >> the same data always. >> There is a button in the application that says enable Ack, and when I >> click, then the hardware start to send all the stored information, and all >> the information is shown. >> >> I write a class, using rxtx that reads the serial port, and the same thing >> happens, it remains reading the same (first) data all the time. And I thing >> something like the enable Ack I'm missing. >> How can I do this enable Ack from my java code using rxtx? >> > Afaik, a look at man ascii reveals: > Okt Dez Hex Char > 006 6 06 ACK > So, i hope this will do the job: > send(6); > > florian > >> >> Thanks in advance >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/7f3fba42/attachment-0013.html From agusmunioz at gmail.com Fri Aug 8 18:39:27 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 21:39:27 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Message-ID: <988288430808081739x7f9e7889id82591d5a9e2b4f6@mail.gmail.com> Ok, Florian, it works!! my problem was that I've been sending, through the OutputStream, the bytes of 6 as a string: out.write("6".getBytes()); but then I realized that you can write an int on an OuptuStream, so I tried that and It works: out.write(6); Thank you for the guidance!! On Fri, Aug 8, 2008 at 7:31 PM, Agustin Mu?oz wrote: > Hi Florian, thanks for the answer. By send(6) you mean to get the port > OutputStream and write a 6? > > I try that but it didn't work. > > Any suggestion? > > Thanks > > > On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < > florianmanschwetus at gmx.de> wrote: > >> Agustin Mu?oz schrieb: >> >> Hi, I'm still learning about serial communication and I have some doubts. >>> I've got this question about how to do the following thing in rxtx. >>> I have this hardware that connect to a PC using a serial port. These >>> hardware receives data from a telephone line, proccess it, and then send it >>> forward to the serial port. I've used a program named wincomm that shows >>> what information is send it through the serial port and I have the nex >>> behaviour: >>> >>> The hardware has a buffer where all data is stored, that cannot be sent >>> it through the seria port. >>> The program reads the first data send it by the hardware, and keep >>> reading the same data always. >>> There is a button in the application that says enable Ack, and when I >>> click, then the hardware start to send all the stored information, and all >>> the information is shown. >>> >>> I write a class, using rxtx that reads the serial port, and the same >>> thing happens, it remains reading the same (first) data all the time. And I >>> thing something like the enable Ack I'm missing. >>> How can I do this enable Ack from my java code using rxtx? >>> >> Afaik, a look at man ascii reveals: >> Okt Dez Hex Char >> 006 6 06 ACK >> So, i hope this will do the job: >> send(6); >> >> florian >> >>> >>> Thanks in advance >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/b918ab3d/attachment-0013.html From florianmanschwetus at gmx.de Sat Aug 9 00:45:43 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Sat, 09 Aug 2008 08:45:43 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4899667C.6010706@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> Message-ID: <489D3D17.9090209@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >> Florian Manschwetus wrote: >>> Ok, sounds fine for the receiving problem. >>> But why i have to wait after each byte when sending a command squence? >>> (the for loop in send command) >> >> Hi Florian, >> I'd imagine you probably don't! You could send all bytes in one go and >> RXTX would send them. The problem is most probably the other end: >> perhaps it has a really small buffer, some non-standard UART, or a >> crazy timing issue. If you attach a terminal to your output and send >> all the bytes of a command in one go they should appear no problem. >> >> Regards, >> Michael Erskine. >> > correct with a terminal on the other end it works, my idea was that this > basic baud has some influence. Could some one explain what it is for? > > Florian To make it more clear, my problem is that i can't use: outputStream.write(byte[]); => Beamer doesn't understand the sequence. (mostly no answer when he answers then *001) when i use this construct instead: for (int i = 0; i < command.length; i++) { this.outputStream.write(command[i]); try { Thread.sleep(25); } catch (InterruptedException e) { // TODO Auto-generated catch block e.printStackTrace(); } } it works nearly reliable. So what could it be? This Basic Baud is what exactly? Florian -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080809/692304ee/attachment-0013.bin From tjarvi at qbang.org Sat Aug 9 16:37:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Aug 2008 16:37:19 -0600 (MDT) Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489D3D17.9090209@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> <489D3D17.9090209@gmx.de> Message-ID: On Sat, 9 Aug 2008, Florian Manschwetus wrote: > Florian Manschwetus schrieb: >> Michael Erskine schrieb: >>> Florian Manschwetus wrote: >>>> Ok, sounds fine for the receiving problem. >>>> But why i have to wait after each byte when sending a command squence? >>>> (the for loop in send command) >>> >>> Hi Florian, >>> I'd imagine you probably don't! You could send all bytes in one go and >>> RXTX would send them. The problem is most probably the other end: perhaps >>> it has a really small buffer, some non-standard UART, or a crazy timing >>> issue. If you attach a terminal to your output and send all the bytes of a >>> command in one go they should appear no problem. >>> >>> Regards, >>> Michael Erskine. >>> >> correct with a terminal on the other end it works, my idea was that this >> basic baud has some influence. Could some one explain what it is for? >> >> Florian > To make it more clear, > my problem is that i can't use: > outputStream.write(byte[]); > => Beamer doesn't understand the sequence. (mostly no answer when he answers > then *001) > > when i use this construct instead: > > for (int i = 0; i < command.length; i++) { > this.outputStream.write(command[i]); > try { > Thread.sleep(25); > } catch (InterruptedException e) { > // TODO Auto-generated catch block > e.printStackTrace(); > } > } > > it works nearly reliable. > > So what could it be? This Basic Baud is what exactly? > I suspect you are using the 'moon protocol' and don't know it. RXTX enables this by default. The buffer on the other end is first in first out while reading. If the buffer is full, the bits are hand carried to the moon and burried. Then if the other side reads a couple bytes, two more bytes go into the buffer followed by more moon protocol. The resulting array of bytes the other side reads may appear to be scrambled until you go to the moon, get the bits and insert them in the right place. Flow control can prevent the default moon protocol and throttles the communiation by almost writing a byte at a time as need be. Hardware flow control is preferable but software flow control should also work. Read and write can appear to hang if the other side is not connected. This is why we don't enable them all the time. If you can't use flow control, you have to take care with the moon protocol and give the other side time to read. That is what your slower version of write is doing. -- Trent Jarvi tjarvi at qbang.org From rxtx at allenjb.me.uk Mon Aug 11 08:06:36 2008 From: rxtx at allenjb.me.uk (AllenJB) Date: Mon, 11 Aug 2008 15:06:36 +0100 Subject: [Rxtx] Disabling EV_RXFLAG Message-ID: <48A0476C.2090800@allenjb.me.uk> Hi all, I'm working with a device which does not use an EvtChar and need to disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an event mask of FD 01 00 00. The reference software I have uses FB 00 00 00. With the rxtx mask I get framing errors which I believe are caused when the EvtChar is received. Is there currently a way with rxtx (I've using rxtx from Java) to disable EV_RXFLAG? If not from Java, where would I start if I wanted to turn the EV_RXFLAG option off in the C code? I've had a grep of the rxtx source code, but I can't see where EV_RXFLAG is being set. Thanks in advance, AllenJB From tjarvi at qbang.org Mon Aug 11 14:17:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Aug 2008 14:17:27 -0600 (MDT) Subject: [Rxtx] Disabling EV_RXFLAG In-Reply-To: <48A0476C.2090800@allenjb.me.uk> References: <48A0476C.2090800@allenjb.me.uk> Message-ID: On Mon, 11 Aug 2008, AllenJB wrote: > Hi all, > > I'm working with a device which does not use an EvtChar and need to > disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an > event mask of FD 01 00 00. The reference software I have uses FB 00 00 > 00. With the rxtx mask I get framing errors which I believe are caused > when the EvtChar is received. > > Is there currently a way with rxtx (I've using rxtx from Java) to > disable EV_RXFLAG? > > If not from Java, where would I start if I wanted to turn the EV_RXFLAG > option off in the C code? I've had a grep of the rxtx source code, but I > can't see where EV_RXFLAG is being set. > > Thanks in advance, > > AllenJB Hi Allen, I'd look at termios.c::tcsetattr() and termios.c::FillDCB() -- Trent Jarvi tjarvi at qbang.org From superdadusa at gmail.com Tue Aug 12 13:57:32 2008 From: superdadusa at gmail.com (John Choi) Date: Tue, 12 Aug 2008 13:57:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. Message-ID: Hi all, Just let you all know I just start to learn Java. I have download the serial comm package and the source code from open source communities.. I was able to verify with the given message string via serial monitor. when the given message string sends to the serial port then the character return added to the end of string by default if I use "Hello World" however if I changed to something else other than "Hello, World" there is no character return add to the end of string. I thing the library download from rxtx.org has implemented for the special strings. I can do like "login\n" in the string message to make character return but I don't want to add this individual custom character for each command return in every static message string I send, Can any who have done this might help me? Basically, something like this,, Write and add function to the program write a command, Reads the respond from a serial device.. Function handles multiple messages, Write: "com open" Read: Welcome to my world" expected Write: "admin" Read: Password?, expected Write: "admin" Read: you are successfully login terminal, expected. And I need to add a separate function handler handles a character return add to the each command above. If anyone can help this I can do the reset? Thank you in advance, John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0009.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SerialIO.java Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0009.pl From Steffen.DETTMER at ingenico.com Wed Aug 13 02:16:38 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 13 Aug 2008 10:16:38 +0200 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: References: Message-ID: <20080813081638.GA25412@elberon.bln.de.ingenico.com> * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > I can do like "login\n" in the string message to make character > return but I don't want to add this individual custom character > for each command return in every static message string I send, and why not?! > Can any who have done this might help me? what's about with writing a small wrapper function adding the carriage return? However, this would be slow, because either you call write two times (very bad) or the string needs to be copied, \n appended and written (since you are using Java Performance probably isn't so critical). Personally I would write `"login\n"' and `username + "\n"' etc., because since it is part of the command it should be part of the command definition string. > Basically, something like this,, Write and add function to the program write > a command, Reads the respond from a serial device.. correctly reading a `line' is more difficult. If you cannot make assumptions about timeouts and/or you need to have low delay, you need to read byte wise. If you need to save CPU resources you might need to add some buffering layer that you can read byte-wise but that is reading blockwise with some small timeout (lets say for serial lines something around byte transmission time times three or so). > /* > * To change this template, choose Tools | Templates > * and open the template in the editor. > */ :) > package joliba; > > /** > * > * @author root > */ :) > // derived from SUN's examples in the javax.comm package > import java.io.*; > import java.util.*; > //import javax.comm.*; // for SUN's serial/parallel port libraries > import gnu.io.*; // for rxtxSerial library > > public class SerialIO implements Runnable, SerialPortEventListener { > static CommPortIdentifier portId; > static CommPortIdentifier saveportId; > static Enumeration portList; > InputStream inputStream; > SerialPort serialPort; > Thread readThread; You need a thread for your synchronous RPC-style protocol? > static String messageString = "Hello, world!"; > static OutputStream outputStream; > static boolean outputBufferEmptyFlag = false; > > public static void main(String[] args) { > boolean portFound = false; > String defaultPort; > > // determine the name of the serial port on several operating systems > String osname = System.getProperty("os.name","").toLowerCase(); > if ( osname.startsWith("windows") ) { > // windows > defaultPort = "COM1"; > } else if (osname.startsWith("linux")) { > // linux > defaultPort = "/dev/ttyS0"; > } else if ( osname.startsWith("mac") ) { > // mac > defaultPort = "????"; > } else { > System.out.println("Sorry, your operating system is not supported"); > return; > } Is such a construction recommended? Isn't there some abstraction (like COM1 working on any platform)? [...] > try { > // activate the OUTPUT_BUFFER_EMPTY notifier > serialPort.notifyOnOutputEmpty(true); > } catch (Exception e) { > System.out.println("Error setting event notification"); > System.out.println(e.toString()); > System.exit(-1); > } I doubt that -1 is defined, probably some 127 or so would be the result, maybe better simply `throw e'? > public void writetoport() { > System.out.println("Writing \""+messageString+"\" to "+serialPort.getName()); > try { > // write string to serial port > outputStream.write(messageString.getBytes()); > } catch (IOException e) {} > } maybe something like /** * Writes the given output string and an additional carriage * return to the current outputStream. */ public void writeStringToPort( /** The output string (without CR). */ String output ) throws IOException { String outputLine = output + "\n"; outputStream.write(outputLine.getBytes()); } ? > > public SerialIO() { > // initalize serial port > try { > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > } catch (PortInUseException e) {} if the port is in use, you continue? Wonder that this works in Java, I would assume serialPort beeing uninitialized which AFAIK is an error in Java. > try { > inputStream = serialPort.getInputStream(); > } catch (IOException e) {} > > try { > serialPort.addEventListener(this); > } catch (TooManyListenersException e) {} > > // activate the DATA_AVAILABLE notifier > serialPort.notifyOnDataAvailable(true); > > try { > // set port parameters > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > } catch (UnsupportedCommOperationException e) {} > > // start the read thread > readThread = new Thread(this); > readThread.start(); > > } I think in all those exception cases you can abort, because it is unlikely that ignoring those errors allow a successful continuation, so in this case maybe it would be better to add a throw clause to the method. > public void run() { > // first thing in the thread, we initialize the write operation > initwritetoport(); > try { > while (true) { > // write string to port, the serialEvent will read it > writetoport(); > Thread.sleep(1000); > } > } catch (InterruptedException e) {} > } Does this make sense? Your `SimpleReadApp' writes one and the same string each second? > public void serialEvent(SerialPortEvent event) { > switch (event.getEventType()) { > case SerialPortEvent.BI: > case SerialPortEvent.OE: > case SerialPortEvent.FE: > case SerialPortEvent.PE: > case SerialPortEvent.CD: > case SerialPortEvent.CTS: > case SerialPortEvent.DSR: > case SerialPortEvent.RI: > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > break; > case SerialPortEvent.DATA_AVAILABLE: > // we get here if data has been received > byte[] readBuffer = new byte[20]; > try { > // read data > while (inputStream.available() > 0) { > int numBytes = inputStream.read(readBuffer); > } > // print data > String result = new String(readBuffer); > System.out.println("Read: "+result); > } catch (IOException e) {} I doubt that this is correct. I would assume you will get a 20 bytes result always, if more bytes would be available they would be printed in a second line but if less bytes are read I'd assume that the buffer/result contains zero bytes from implicite readBuffer contents initialisation (zero is no string terminator in Java AFAIK). > break; > } > } > } oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From florianmanschwetus at gmx.de Wed Aug 13 06:09:31 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 13 Aug 2008 14:09:31 +0200 Subject: [Rxtx] someone has seen such errors? Message-ID: <48A2CEFB.90007@gmx.de> I mean my communication mostly works, but it is far from perfect could this be the reason? Florian Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/949b9947/attachment-0009.bin From superdadusa at gmail.com Wed Aug 13 08:40:32 2008 From: superdadusa at gmail.com (John Choi) Date: Wed, 13 Aug 2008 08:40:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: <20080813081638.GA25412@elberon.bln.de.ingenico.com> References: <20080813081638.GA25412@elberon.bln.de.ingenico.com> Message-ID: Thank you so much Steffen and I will try that suggestion. John On 8/13/08, Steffen DETTMER wrote: > > * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > > I can do like "login\n" in the string message to make character > > return but I don't want to add this individual custom character > > for each command return in every static message string I send, > > and why not?! > > > Can any who have done this might help me? > > what's about with writing a small wrapper function adding the > carriage return? > However, this would be slow, because either you call write two > times (very bad) or the string needs to be copied, \n appended > and written (since you are using Java Performance probably isn't > so critical). > > Personally I would write `"login\n"' and `username + "\n"' etc., > because since it is part of the command it should be part of the > command definition string. > > > Basically, something like this,, Write and add function to the program > write > > a command, Reads the respond from a serial device.. > > correctly reading a `line' is more difficult. If you cannot make > assumptions about timeouts and/or you need to have low delay, you > need to read byte wise. If you need to save CPU resources you > might need to add some buffering layer that you can read > byte-wise but that is reading blockwise with some small timeout > (lets say for serial lines something around byte transmission > time times three or so). > > > /* > > * To change this template, choose Tools | Templates > > * and open the template in the editor. > > */ > > :) > > > package joliba; > > > > /** > > * > > * @author root > > */ > > :) > > > // derived from SUN's examples in the javax.comm package > > import java.io.*; > > import java.util.*; > > //import javax.comm.*; // for SUN's serial/parallel port libraries > > import gnu.io.*; // for rxtxSerial library > > > > public class SerialIO implements Runnable, SerialPortEventListener { > > static CommPortIdentifier portId; > > static CommPortIdentifier saveportId; > > static Enumeration portList; > > InputStream inputStream; > > SerialPort serialPort; > > Thread readThread; > > You need a thread for your synchronous RPC-style protocol? > > > static String messageString = "Hello, world!"; > > static OutputStream outputStream; > > static boolean outputBufferEmptyFlag = false; > > > > public static void main(String[] args) { > > boolean portFound = false; > > String defaultPort; > > > > // determine the name of the serial port on several operating > systems > > String osname = System.getProperty("os.name","").toLowerCase(); > > if ( osname.startsWith("windows") ) { > > // windows > > defaultPort = "COM1"; > > } else if (osname.startsWith("linux")) { > > // linux > > defaultPort = "/dev/ttyS0"; > > } else if ( osname.startsWith("mac") ) { > > // mac > > defaultPort = "????"; > > } else { > > System.out.println("Sorry, your operating system is not > supported"); > > return; > > } > > Is such a construction recommended? Isn't there some abstraction > (like COM1 working on any platform)? > > [...] > > try { > > // activate the OUTPUT_BUFFER_EMPTY notifier > > serialPort.notifyOnOutputEmpty(true); > > } catch (Exception e) { > > System.out.println("Error setting event notification"); > > System.out.println(e.toString()); > > System.exit(-1); > > } > > I doubt that -1 is defined, probably some 127 or so would be the > result, maybe better simply `throw e'? > > > public void writetoport() { > > System.out.println("Writing \""+messageString+"\" to > "+serialPort.getName()); > > try { > > // write string to serial port > > outputStream.write(messageString.getBytes()); > > } catch (IOException e) {} > > } > > maybe something like > > /** > * Writes the given output string and an additional carriage > * return to the current outputStream. > */ > public void > writeStringToPort( > /** The output string (without CR). */ > String output > ) throws IOException > { > String outputLine = output + "\n"; > outputStream.write(outputLine.getBytes()); > } > > ? > > > > > public SerialIO() { > > // initalize serial port > > try { > > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > > } catch (PortInUseException e) {} > > if the port is in use, you continue? Wonder that this works in > Java, I would assume serialPort beeing uninitialized which AFAIK > is an error in Java. > > > try { > > inputStream = serialPort.getInputStream(); > > } catch (IOException e) {} > > > > try { > > serialPort.addEventListener(this); > > } catch (TooManyListenersException e) {} > > > > // activate the DATA_AVAILABLE notifier > > serialPort.notifyOnDataAvailable(true); > > > > try { > > // set port parameters > > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > } catch (UnsupportedCommOperationException e) {} > > > > // start the read thread > > readThread = new Thread(this); > > readThread.start(); > > > > } > > I think in all those exception cases you can abort, because it is > unlikely that ignoring those errors allow a successful > continuation, so in this case maybe it would be better to add a > throw clause to the method. > > > public void run() { > > // first thing in the thread, we initialize the write operation > > initwritetoport(); > > try { > > while (true) { > > // write string to port, the serialEvent will read it > > writetoport(); > > Thread.sleep(1000); > > } > > } catch (InterruptedException e) {} > > } > > Does this make sense? Your `SimpleReadApp' writes one and the > same string each second? > > > public void serialEvent(SerialPortEvent event) { > > switch (event.getEventType()) { > > case SerialPortEvent.BI: > > case SerialPortEvent.OE: > > case SerialPortEvent.FE: > > case SerialPortEvent.PE: > > case SerialPortEvent.CD: > > case SerialPortEvent.CTS: > > case SerialPortEvent.DSR: > > case SerialPortEvent.RI: > > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > > break; > > case SerialPortEvent.DATA_AVAILABLE: > > // we get here if data has been received > > byte[] readBuffer = new byte[20]; > > try { > > // read data > > while (inputStream.available() > 0) { > > int numBytes = inputStream.read(readBuffer); > > } > > // print data > > String result = new String(readBuffer); > > System.out.println("Read: "+result); > > } catch (IOException e) {} > > I doubt that this is correct. I would assume you will get a 20 > bytes result always, if more bytes would be available they would > be printed in a second line but if less bytes are read I'd assume > that the buffer/result contains zero bytes from implicite > readBuffer contents initialisation (zero is no string terminator > in Java AFAIK). > > > break; > > } > > } > > } > > oki, > > Steffen > > About Ingenico Throughout the world businesses rely on Ingenico for secure > and expedient electronic transaction acceptance. Ingenico products leverage > proven technology, established standards and unparalleled ergonomics to > provide optimal reliability, versatility and usability. This comprehensive > range of products is complemented by a global array of services and > partnerships, enabling businesses in a number of vertical sectors to accept > transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged > information. If you are not the addressee or authorized to receive this for > the addressee, you must not use, copy, disclose or take any action based on > this message or any information herein. If you have received this message in > error, please advise the sender immediately by reply e-mail and delete this > message. Thank you for your cooperation. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/73c4135c/attachment-0008.html From ajmas at sympatico.ca Sat Aug 16 07:15:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 09:15:41 -0400 Subject: [Rxtx] someone has seen such errors? In-Reply-To: <48A2CEFB.90007@gmx.de> References: <48A2CEFB.90007@gmx.de> Message-ID: <43B5E8DA-1D93-4D90-809B-AAF35FF724C5@sympatico.ca> On 13-Aug-08, at 08:09 , Florian Manschwetus wrote: > I mean my communication mostly works, but it is far from perfect > could this be the reason? > > Florian > > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control Judging by the error messages this looks related to the driver you are using. Do a search for the following string with you favourite search engine, it should turn up a few hits: ftdi_set_termios FAILED to set databits/stopbits/parity Andre From ajmas at sympatico.ca Sat Aug 16 19:12:04 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 21:12:04 -0400 Subject: [Rxtx] Using SerialPortEvent? Message-ID: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Hi, Could someone tell me how I should be using the SerialPortEvent? Am I meant to be waiting for data and then simply reading from the inputstream? If this is the case why no just block on an inputstream read? Andr? From tjarvi at qbang.org Sat Aug 16 19:41:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 16 Aug 2008 19:41:13 -0600 (MDT) Subject: [Rxtx] Using SerialPortEvent? In-Reply-To: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> References: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Message-ID: On Sat, 16 Aug 2008, Andre-John Mas wrote: > Hi, > > Could someone tell me how I should be using the SerialPortEvent? Am I > meant to be waiting for data and then simply reading from the > inputstream? If this is the case why no just block on an inputstream > read? > Polling for data is fine also. It really depends upon what you are trying to do. For instance, if you require x bytes before reading, you can start polling after data is available. If you read on the same thread as your GUI and are waiting for data in a read, the results may be less than desirable. Java programming is 'usually' event driven rather than polling based. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sat Aug 16 20:10:39 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 22:10:39 -0400 Subject: [Rxtx] Using SerialPortEvent? In-Reply-To: References: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Message-ID: <3E495D4C-BB28-4845-A6AB-984C9A826BDF@sympatico.ca> On 16-Aug-08, at 21:41 , Trent Jarvi wrote: > On Sat, 16 Aug 2008, Andre-John Mas wrote: > >> Hi, >> >> Could someone tell me how I should be using the SerialPortEvent? Am I >> meant to be waiting for data and then simply reading from the >> inputstream? If this is the case why no just block on an inputstream >> read? >> > > Polling for data is fine also. It really depends upon what you are > trying to do. For instance, if you require x bytes before reading, > you can start polling after data is available. If you read on the > same thread as your GUI and are waiting for data in a read, the > results may be less than desirable. > > Java programming is 'usually' event driven rather than polling based. Sounds good. I thought I would use this opportunity to provide a event based version of the TwoWaySerialComm example. Could you just validate it before I add it to the Wiki: package ajmas74.experimental; import gnu.io.CommPort; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; import gnu.io.SerialPortEvent; import gnu.io.SerialPortEventListener; import java.io.IOException; import java.io.InputStream; import java.io.OutputStream; /** * This version of the TwoWaySerialComm example makes use of the * SerialPortEventListener to avoid polling. * * @author ajmas * */ public class TwoWaySerialComm { public TwoWaySerialComm() { super(); } void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { CommPort commPort = portIdentifier.open(this.getClass().getName(),2000); if ( commPort instanceof SerialPort ) { SerialPort serialPort = (SerialPort) commPort; serialPort .setSerialPortParams (57600 ,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); (new Thread(new SerialWriter(out))).start(); serialPort.addEventListener(new SerialReader(in)); } else { System.out.println("Error: Only serial ports are handled by this example."); } } } /** * Handles the input coming from the serial port. A new line character * is treated as the end of a block in this example. */ public static class SerialReader implements SerialPortEventListener { private InputStream in; private byte[] buffer = new byte[1024]; public SerialReader ( InputStream in ) { this.in = in; } public void serialEvent(SerialPortEvent arg0) { int data; try { int len = 0; while ( ( data = in.read()) > -1 ) { if ( data != '\n' ) { break; } buffer[len++] = (byte) data; } System.out.print(new String(buffer,0,len)); } catch ( IOException e ) { e.printStackTrace(); System.exit(-1); } } } /** */ public static class SerialWriter implements Runnable { OutputStream out; public SerialWriter ( OutputStream out ) { this.out = out; } public void run () { try { int c = 0; while ( ( c = System.in.read()) > -1 ) { this.out.write(c); } } catch ( IOException e ) { e.printStackTrace(); System.exit(-1); } } } public static void main ( String[] args ) { try { (new TwoWaySerialComm()).connect("COM3"); } catch ( Exception e ) { e.printStackTrace(); } } } From lfarkas at lfarkas.org Tue Aug 19 07:32:59 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Tue, 19 Aug 2008 15:32:59 +0200 Subject: [Rxtx] JNI or CNI Message-ID: <48AACB8B.9060606@lfarkas.org> hi, what is the current recommended way to rxtx on linux JNI or it's better to use CNI? is the CNI version fully functional and the same level as the JNI? i currently try to make a rhel/centos/fedora rpm for rxtx but has many problems with the standard dir structure. yours. -- Levente "Si vis pacem para bellum!" From lfarkas at lfarkas.org Tue Aug 19 08:47:34 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Tue, 19 Aug 2008 16:47:34 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel Message-ID: <48AADD06.7040809@lfarkas.org> hi, newer or not so newer linux kernel do not contain the UTS_RELEASE so the current rxtx is not compile on the latest kernels. even if it's commented out in the cvs configure there are other places. i attcahed a patch which fix it (or at least doesn't cause error at non-debug build). ps. is there any plan to the new 2.1-8 release in the near future? there are many changes (at least the license change in all file and in this case create a diff is very difficult)? the latest release more then 2 years old:-( -- Levente "Si vis pacem para bellum!" -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-2.1-uts.patch Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080819/ab5d38ac/attachment-0001.pl From ajmas at sympatico.ca Tue Aug 19 16:21:53 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 19 Aug 2008 18:21:53 -0400 Subject: [Rxtx] Event based example Message-ID: <24735BFB-B088-4B84-8173-FE98DF63B12F@sympatico.ca> Hi, I have just posted an example of using SerialPortEventListener in the Wiki: http://rxtx.qbang.org/wiki/index.php/Event_Based_Two_Way_Communication If you see any issues please could you let me know, or makes the changes. Andre From rick_knight at rlknight.com Mon Aug 4 13:25:10 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Mon, 04 Aug 2008 12:25:10 -0700 Subject: [Rxtx] Sun's Comm API? Message-ID: <48975796.4010600@rlknight.com> I have an application that requires the javax compatible version of RXTX and Sun's comm api. I've been able to download and extract the version of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api anywhere. Can someone tell me where I can find it? Or maybe send me a copy? Also, when I try to build RXTX, configure and make complete successfully but make install failes with this error libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 I've never come accross this error before. How can I get past it? Thanks, Rick From bboyes at systronix.com Mon Aug 4 19:10:01 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:10:01 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48975796.4010600@rlknight.com> References: <48975796.4010600@rlknight.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/cb9c6167/attachment-0018.html From bboyes at systronix.com Mon Aug 4 19:12:37 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:12:37 -0600 Subject: [Rxtx] Towards an RXTX release - CSR BT/USB chipset In-Reply-To: <488FB7E7.8000802@gmail.com> References: <460801A4097E3D4CA04CC64EE648584806C56CF0@ism-mail03.corp.ad.wrs.com> <13557-75390@sneakemail.com> <20980-23424@sneakemail.com> <488FB7E7.8000802@gmail.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/52236088/attachment-0018.html From tjarvi at qbang.org Mon Aug 4 19:42:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 19:42:21 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: On Mon, 4 Aug 2008, Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: > I have an application that requires the javax compatible > version of RXTX > and Sun's comm api. I've been able to download and extract > the version > of RXTX that I need (2.0-7pre2) but I can't find Sun's camm > api > anywhere. Can someone tell me where I can find it? Or maybe > send me a > > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm port > support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have just > a ZIP with only the .class JAR file - no source or docs), has a readme > with these comments: > > This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release.? The 2.0.3 release itself is > no longer distributed.? comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project.? The RxTx project (http://www.rxtx.org ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org) was opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support.? Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins.? Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > ? > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > I hope that is helpful! > It would be nice to work with Sun to resolve those longstanding issues. But it may not be practical unless the process goes as fast and painless as the grandfathering of commapi did. Another option may be the old kaffe extensions that moved to gnu classpathx. These don't have the native libraries but should provide the 2.0 interface and the javax.comm.properties mechansim for SPI. http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Mon Aug 4 20:23:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Mon, 04 Aug 2008 20:23:57 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4897B9BD.5070809@ergotech.com> Has there been any work/would it be possible, to layer a javacomm look-alike on top of the GNU code? The goal is not to move the javax code forward, but to emulate the "legacy" javax packages for people who still need this. Jim Trent Jarvi wrote: > On Mon, 4 Aug 2008, Bruce Boyes wrote: > >> At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible >> version of RXTX >> and Sun's comm api. I've been able to download and extract >> the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm >> api >> anywhere. Can someone tell me where I can find it? Or maybe >> send me a >> >> >> javaxcomm has had a sort of on-again off-again history. The windoze >> version has been languishing for years (literally) but there are newer >> versions for other OS's. >> >> We try to keep links on one of our help pages current: >> http://www.practicalembeddedjava.com/tools/javatools_list.html >> which gets you to here: >> http://java.sun.com/products/javacomm/ >> where it says in fact they no longer even support Windows and Mac: >> "Implementations of the API are currently available for Solaris SPARC, >> Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so >> someone could support it. But I guess that's part of the reason RXTX >> exists! >> >> So one of Sun's own products, SunSPOT, has to use RXTX to get comm port >> support. >> >> The version we use is 2.0 from 11/15/1998. I have posted it on our >> website, which is within the terms of the license agreement contained >> therein (as I understand it). >> >> The last version of javaxcomm for Windows, 2.0.3, (for which I have just >> a ZIP with only the .class JAR file - no source or docs), has a readme >> with these comments: >> >> This distribution contains the comm.jar file original part >> of the COMMAPI 2.0.3 release. The 2.0.3 release itself is >> no longer distributed. comm.jar, which contains the comm >> API java class files (eg. Sun's binary implementation of the >> interface classes), is being made available, unsupported, >> with no obligation to fix bugs, at the request of the RXTX >> project. The RxTx project (http://www.rxtx.org ), uses the >> comm.jar class files, but provides their own native library >> components to provide support for other platforms. >> >> The 2.0.3 comm.jar is being provided in this way because >> as of COMMAPI 3.x, the java binary implementation forked and >> became incompatible with the RxTx project's native code. >> Due to the lack of a clear business case, and to resource >> constraints, no additional resources are being >> provided to provide an alternative engineering solution >> at the time of writing. >> >> RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: >> >> Ultimately the COMMAPI would be better served if a Java >> Community Process JSR (http://www.jcp.org) was opened and >> the COMMAPI was rearchitected to provide a more pluggable >> framework to improve cross-platform support. Such an >> architecture would embody a better defined and better >> documented SPI interface, including a way for comm. ports >> to be revealed to the client application through the API >> via platform-aware plugins. Similarly, native code used >> to access comm port in general could be handled more >> flexibly using a plugin model, whereby on any platform, >> multiple native modules could be in use simultaneously. >> >> Since there are now various ways serial ports can be implemented >> and accessed, modular comm. port JNI native libraries would be >> of benefit insofar as removing the burden of over-generalization >> from any single native component, or inversely, by relieving the >> implicit constraint that comm. drivers be accessed only via a >> monolithic mechanism, such as the UNIX vnode interface. >> >> paul.klissner at sun.com >> 6/10/06 >> >> I hope that is helpful! >> > > It would be nice to work with Sun to resolve those longstanding issues. > But it may not be practical unless the process goes as fast and painless > as the grandfathering of commapi did. > > Another option may be the old kaffe extensions that moved to gnu > classpathx. These don't have the native libraries but should provide > the 2.0 interface and the javax.comm.properties mechansim for SPI. > > http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Mon Aug 4 21:09:15 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 21:09:15 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? Message-ID: Hi Jim, I will not step into the javax.comm namespace without Sun's explicite permission. I fully understand the pain point you are trying to address. In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm Linux) - which remains an integral part of rxtx. At the time it was a win for Sun and rxtx. The Sun commapi license is/was fairly clear that rxtx should not step into that namespace. It made sense as Sun was active in that space and rxtx may go into another namespace - it was an experiment in working with Sun. This may sound silly looking at something that happened almost 10 years ago. In a community of respect which Sun helped create, there is no question about what to do. I hope eventually Sun will step up and do a right thing too. I agree that this is hurting the API more than helping it. There are also questions about how to replace the API in the long term which includes HID support which isn't going well so far. Others that can't even look at Sun's javax.comm today and can look at Kaffe's contribution to classpathx can easily work around such restrictions. On Mon, 4 Aug 2008, Jim Redman wrote: > Has there been any work/would it be possible, to layer a javacomm > look-alike on top of the GNU code? > > The goal is not to move the javax code forward, but to emulate the > "legacy" javax packages for people who still need this. > > Jim > > Trent Jarvi wrote: >> >> It would be nice to work with Sun to resolve those longstanding issues. >> But it may not be practical unless the process goes as fast and painless >> as the grandfathering of commapi did. >> >> Another option may be the old kaffe extensions that moved to gnu >> classpathx. These don't have the native libraries but should provide >> the 2.0 interface and the javax.comm.properties mechansim for SPI. >> >> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From florianmanschwetus at gmx.de Tue Aug 5 05:04:46 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 13:04:46 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: References: <48971C1F.9020806@gmx.de> Message-ID: <489833CE.1040801@gmx.de> Just look at sendCommand in this method I have to place a Thread.sleep(20) after each byte send to get working. Even the event based receive doesn't work fine but this could be may stupidness. The specifikation document (it is on the last pages of the manual) for the beamer could be found on: http://www.optoma.co.uk/support.aspx Florian Manschwetus Trent Jarvi schrieb: > > Hi Florian > > Sorry for the top post in advance. I worry you may not see my answer > under all your code :) > > I have not received this email before. This is 500k of code which I > don't have time to read. I can spend about 5 min on each hobby email > and still get to work in the morning. I have a couple suggestions for > how to get an answer. > > First, cut out your comments and extra code so you can demonstrate the > question (I might even glance and see what is wrong then). Don't go for > a working final product. Isolate the problem using a simple program and > then ask with that as an example. If I did what you just did, I'd have > to post 3/4 of a million lines of code :) > > Second, join the rxtx mail-list and ask there. This will give you 100x > more eyes. I'll also read and try to follow. > > -- > taj > > > > On Mon, 4 Aug 2008, Florian Manschwetus wrote: > >> It could be that my university account is blocked by filters so >> resending from here. >> >> >> Topic is to control Optoma HD80 beamer using rs232 serial chat. >> This code is able to detect power state and switch the beamer on / off. >> connected is the beamer using a digitus usb 2.0 serial adapter with an >> FT232 USB-Serial adapter the systems architecture is amd64. >> >> Please take a look in the sendCommand routine i have to place theire >> those Thread.sleep to get it working. >> Now the question is this correct or is there a better way to get this >> working correctly? >> >> In the javadoc coming with the install i found this: >> setBaudBase >> >> public boolean setBaudBase(int BaudBase) >> throws UnsupportedCommOperationException, >> java.io.IOException >> >> Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 >> before using. >> >> could this explain the error? >> I attached my java source and the protocol description for the beamer >> (available on vendor website). >> >> thx, >> Florian Manschwetus >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: TestRS232.java Type: text/x-java Size: 9143 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0036.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0037.bin From michael.erskine at ketech.com Tue Aug 5 05:53:49 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Tue, 5 Aug 2008 12:53:49 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489833CE.1040801@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> > Just look at sendCommand in this method I have to place a > Thread.sleep(20) after each byte send to get working. Even the event > based receive doesn't work fine but this could be may stupidness. Hi Florian, Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. Regards, Michael Erskine. From florianmanschwetus at gmx.de Tue Aug 5 07:28:15 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:28:15 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> Message-ID: <4898556F.8000208@gmx.de> Michael Erskine schrieb: >> Just look at sendCommand in this method I have to place a >> Thread.sleep(20) after each byte send to get working. Even the event >> based receive doesn't work fine but this could be may stupidness. > > Hi Florian, > > Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. > > Regards, > Michael Erskine. > Ok, sounds fine for the receiving problem. But why i have to wait after each byte when sending a command squence? (the for loop in send command) Florian > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/284f350c/attachment-0017.bin From florianmanschwetus at gmx.de Tue Aug 5 07:44:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:44:14 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <4898592E.2020908@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >>> Just look at sendCommand in this method I have to place a >>> Thread.sleep(20) after each byte send to get working. Even the event >>> based receive doesn't work fine but this could be may stupidness. >> >> Hi Florian, >> >> Yes, naturally you'll have to wait for a response from the other end. >> Why not wait for notification from the event thread perhaps using a >> BlockingDeque rather than your LinkedList. Generally I >> try to decouple all input and output streams: in your case your >> application is operating synchronously like the "expect" program >> (http://expect.nist.gov/) so waits (or timeouts) will need to be >> factored in. >> >> Regards, >> Michael Erskine. >> > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) > > Florian Furthermore there is this basic baud with this confusing javadoc entry: public boolean setBaudBase(int BaudBase) throws UnsupportedCommOperationException, java.io.IOException Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 before using. maybe this could explain something Florian >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/006c7425/attachment-0017.bin From jredman at ergotech.com Tue Aug 5 09:13:36 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 05 Aug 2008 09:13:36 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: Message-ID: <48986E20.3060104@ergotech.com> Trent, So two issues: 1) Technically I'm still not sure how easy/practical a layer would be. The problems are always classes like listeners, and wrapping returns of gnu.io classes. I really see it as a "delegate" type of concept. Any thoughts or ideas of the practicality of this approach? The idea is not to modify RXTX. 2) Javax. The javax namespace does seem to be in widespread use outside of Sun (the same is true for the java namespace). The classpath extensions, or some other location, should be interested in a JavaComm implementation even if it does have dependencies on RXTX. Would you have any philosophical objection to an approach like that? Of course, I suspect it might be better if someone with that authority at Sun would admit that the javax namespace is already in the wild and that there is no problem with it being used within RXTX. Jim Trent Jarvi wrote: > Hi Jim, > > I will not step into the javax.comm namespace without Sun's explicite > permission. I fully understand the pain point you are trying to address. > > In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm > Linux) - which remains an integral part of rxtx. At the time it was a win for > Sun and rxtx. > > The Sun commapi license is/was fairly clear that rxtx should not step into that > namespace. It made sense as Sun was active in that space and rxtx may go into > another namespace - it was an experiment in working with Sun. > > This may sound silly looking at something that happened almost 10 years ago. > In a community of respect which Sun helped create, there is no question about > what to do. I hope eventually Sun will step up and do a right thing too. > > I agree that this is hurting the API more than helping it. There are also > questions about how to replace the API in the long term which includes HID > support which isn't going well so far. > > Others that can't even look at Sun's javax.comm today and can look at Kaffe's > contribution to classpathx can easily work around such restrictions. > > On Mon, 4 Aug 2008, Jim Redman wrote: > >> Has there been any work/would it be possible, to layer a javacomm >> look-alike on top of the GNU code? >> >> The goal is not to move the javax code forward, but to emulate the >> "legacy" javax packages for people who still need this. >> >> Jim >> >> Trent Jarvi wrote: >>> It would be nice to work with Sun to resolve those longstanding issues. >>> But it may not be practical unless the process goes as fast and painless >>> as the grandfathering of commapi did. >>> >>> Another option may be the old kaffe extensions that moved to gnu >>> classpathx. These don't have the native libraries but should provide >>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>> >>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From sandeep at genevasoftech.com Tue Aug 5 11:18:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Tue, 05 Aug 2008 22:48:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <48988B6C.5080409@genevasoftech.com> Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. *-- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/ad20f1cb/attachment-0017.html From Martin.Oberhuber at windriver.com Tue Aug 5 13:30:17 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Tue, 5 Aug 2008 21:30:17 +0200 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Sandeep, shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on Sol7 but I've successfully run it on Sol9 and Sol10. Or is your request really about a native 64bit variant? I'm afraid that then you're out of luck since I think that quite a bit of RXTX is not yet ready for 64 bit. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Sandeep Kumar K Sent: Tuesday, August 05, 2008 7:19 PM To: rxtx at qbang.org Subject: [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so for Solaris 9 Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. -- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/81b7f988/attachment-0017.html From tjarvi at qbang.org Tue Aug 5 22:38:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 22:38:34 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 5 Aug 2008, Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built > on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid that > then > you're out of luck since I think that quite a bit of RXTX is not yet > ready > for 64 bit. > While rxtx-2.1-7 probably has problems, The CVS code should be OK for 64 bit Solaris. If it isn't, let me know and I'll find which patch is missing. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Aug 5 23:13:00 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 23:13:00 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48986E20.3060104@ergotech.com> References: <48986E20.3060104@ergotech.com> Message-ID: On Tue, 5 Aug 2008, Jim Redman wrote: > Trent, > > So two issues: > > 1) Technically I'm still not sure how easy/practical a layer would be. The > problems are always classes like listeners, and wrapping returns of gnu.io > classes. I really see it as a "delegate" type of concept. Any thoughts or > ideas of the practicality of this approach? The idea is not to modify RXTX. I have not put too much thought into this. I assume you want what rxtx 2.0 provided to tie into javax.comm implementations. More classes could be added to rxtx 2.1-7 for SPI support. Maintaining rxtx-2.0 could also be handed to someone if they like. > > 2) Javax. The javax namespace does seem to be in widespread use outside of > Sun (the same is true for the java namespace). The classpath extensions, or > some other location, should be interested in a JavaComm implementation even > if it does have dependencies on RXTX. Would you have any philosophical > objection to an approach like that? > No problems. Classpathx would be a possible place to do it. I'd suggest thinking twice about what this involves in practical terms. You would be wanting to revive the 2.0 API while Sun is at 3.0 and grandfathering the JSR. This undermines the main reason (established api) for using the javax.comm namespace and does not leave such a project in a good position. The only win I see here is maintaining support for applications that can't migrate namespaces. Not that that isn't important. At some point it is going to be less work to just edit the bytecode :) Such a javax.comm effort would also be signing up new projects that decided to use the work up for concerns they probably will not understand or expect. That probably isn't a good path to facilitate for new projects at this time. We will put a good faith effort to work well with others but keep in mind the project has limited bandwidth for such efforts. > Of course, I suspect it might be better if someone with that authority at Sun > would admit that the javax namespace is already in the wild and that there is > no problem with it being used within RXTX. > > Jim > > Trent Jarvi wrote: >> Hi Jim, >> >> I will not step into the javax.comm namespace without Sun's explicite >> permission. I fully understand the pain point you are trying to address. >> >> In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java >> Comm Linux) - which remains an integral part of rxtx. At the time it was a >> win for Sun and rxtx. >> >> The Sun commapi license is/was fairly clear that rxtx should not step into >> that namespace. It made sense as Sun was active in that space and rxtx may >> go into another namespace - it was an experiment in working with Sun. >> >> This may sound silly looking at something that happened almost 10 years >> ago. In a community of respect which Sun helped create, there is no >> question about what to do. I hope eventually Sun will step up and do a >> right thing too. >> >> I agree that this is hurting the API more than helping it. There are also >> questions about how to replace the API in the long term which includes HID >> support which isn't going well so far. >> >> Others that can't even look at Sun's javax.comm today and can look at >> Kaffe's contribution to classpathx can easily work around such >> restrictions. >> >> On Mon, 4 Aug 2008, Jim Redman wrote: >> >>> Has there been any work/would it be possible, to layer a javacomm >>> look-alike on top of the GNU code? >>> >>> The goal is not to move the javax code forward, but to emulate the >>> "legacy" javax packages for people who still need this. >>> >>> Jim >>> >>> Trent Jarvi wrote: >>>> It would be nice to work with Sun to resolve those longstanding issues. >>>> But it may not be practical unless the process goes as fast and painless >>>> as the grandfathering of commapi did. >>>> >>>> Another option may be the old kaffe extensions that moved to gnu >>>> classpathx. These don't have the native libraries but should provide >>>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>>> >>>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From sandeep at genevasoftech.com Wed Aug 6 00:03:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Wed, 06 Aug 2008 11:33:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: <48993EB8.30107@genevasoftech.com> Thank you Mr. Martin for your suggestion. The native file which is given in rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am getting the following error . Any suggestions to solve this issue. I am using Solaris SPARC 64 bit machine. ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) thrown while loading gnu.io.RXTXCommDriver Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(Unknown Source) at java.lang.ClassLoader.loadLibrary(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) at com.ReadFromModem.main(ReadFromModem.java:84) * * *Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid > that then > you're out of luck since I think that quite a bit of RXTX is not yet ready > for 64 bit. > > Cheers, > -- > *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > ------------------------------------------------------------------------ > *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On > Behalf Of *Sandeep Kumar K > *Sent:* Tuesday, August 05, 2008 7:19 PM > *To:* rxtx at qbang.org > *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so > for Solaris 9 > > Hi, > > Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 > bit machine. The librxtxSerial.so given in website is for Solaris 8. > > *-- > > Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/1e920343/attachment-0017.html From tjarvi at qbang.org Wed Aug 6 00:21:42 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 00:21:42 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <48993EB8.30107@genevasoftech.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> <48993EB8.30107@genevasoftech.com> Message-ID: Hi Sandeep You may be out of luck unless you can compile the 2.1 src in CVS (requires gnu make and gcc). But you could try the ToyBox(R)(TM) which is a collection of WiLdLy untested cross compiled 2.1-7 binaries covering everything from the ibm z series to embeded arm/ppc. To give an idea how poorly these are tested, I don't even know if z series machines have a serial port. ftp://www.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Solaris They should at least match the binary types. Actually, I think if you use the rxtx jar from CVS with that file, it should 'work' as the fix for 64 bits was in java not the native code. You could just cd rxtx*/src; javac *.java then jar -cf RXTXcomm.jar `find -name \*.class` to create the hybrid which will complain about version information a bit. On Wed, 6 Aug 2008, Sandeep Kumar K wrote: > Thank you Mr. Martin for your suggestion. The native file which is given in > rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am > getting the following error . > Any suggestions to solve this issue. > I am using Solaris SPARC 64 bit machine. > > ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar > java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 > (Possible cause: architecture word > width mismatch) thrown while loading gnu.io.RXTXCommDriver > Exception in thread "main" java.lang.UnsatisfiedLinkError: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF > class: ELFCLASS64 (Possible cause: > architecture word width mismatch) > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(Unknown Source) > at java.lang.ClassLoader.loadLibrary(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > at com.ReadFromModem.main(ReadFromModem.java:84) > > * > * > > *Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > > > Oberhuber, Martin wrote: >> Sandeep, >> shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse >> variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on >> Sol7 but I've successfully run it on Sol9 and Sol10. >> Or is your request really about a native 64bit variant? I'm afraid that >> then >> you're out of luck since I think that quite a bit of RXTX is not yet ready >> for 64 bit. >> Cheers, >> -- >> *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> ------------------------------------------------------------------------ >> *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On >> Behalf Of *Sandeep Kumar K >> *Sent:* Tuesday, August 05, 2008 7:19 PM >> *To:* rxtx at qbang.org >> *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so >> for Solaris 9 >> >> Hi, >> >> Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 >> bit machine. The librxtxSerial.so given in website is for Solaris 8. >> >> *-- >> Thanks & Regards >> >> Sandeep Kumar K >> Sr. Software Engineer >> Geneva Software Technologies >> Whitefield, Bangalore >> Mob : 9880193454* >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> From michael.erskine at ketech.com Wed Aug 6 01:39:28 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 6 Aug 2008 08:39:28 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Florian Manschwetus wrote: > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) Hi Florian, I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. Regards, Michael Erskine. From florianmanschwetus at gmx.de Wed Aug 6 02:53:16 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 06 Aug 2008 10:53:16 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Message-ID: <4899667C.6010706@gmx.de> Michael Erskine schrieb: > Florian Manschwetus wrote: >> Ok, sounds fine for the receiving problem. >> But why i have to wait after each byte when sending a command squence? >> (the for loop in send command) > > Hi Florian, > I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. > > Regards, > Michael Erskine. > correct with a terminal on the other end it works, my idea was that this basic baud has some influence. Could some one explain what it is for? Florian > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/c2b4fa84/attachment-0017.bin From rick_knight at rlknight.com Wed Aug 6 13:01:07 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:01:07 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F4F3.3020707@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > I have an application (Readerware) that uses RXTX with Javax to access the serial port. This used to work fine under previous Linux' and Java, but something has changed, I assume with Java itself , that is causing the application to fail with a link error. The application is not able to find librxtxSerialParallel.so. RXTX supplies librxtxSerial.so and librxtxParallel.so, but not librxtxSerialParallel.so. Where can I get librxtxSerialParallel.so, or do I need it? Is something else causing the lib to not be found? Thanks, Rick Knight From rick_knight at rlknight.com Wed Aug 6 13:17:55 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:17:55 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F8E3.5060400@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Thanks for the reply. The developer of the app I'm trying to use (Readerware) has sent me a copy of the comm.api and I've copied the library (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar into the proper places. When I try to run the application, I get this error... Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: /usr/lib/libSolarisSerialParallel.so: /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not little-endian (Possible cause: endianness mismatch) Caught java.lang.UnsatisfiedLinkError: com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I while loading driver com.sun.comm.SolarisDriver Is there a way around this error? Thanks again, Rick Knight From jlar310 at gmail.com Wed Aug 6 13:37:42 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 14:37:42 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899F8E3.5060400@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > The developer of the app I'm trying to use (Readerware) has sent me a > copy of the comm.api and I've copied the library > (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar > into the proper places. When I try to run the application, I get this > error... > > Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: > /usr/lib/libSolarisSerialParallel.so: > /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not > little-endian (Possible cause: endianness mismatch) > Caught java.lang.UnsatisfiedLinkError: > com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I > > while loading driver com.sun.comm.SolarisDriver > > Is there a way around this error? What host OS are you running? From your original post it looks like 32 bit Linux. The libSolarisSerialParallel.so file is for Sun Solaris and will vary depending on the underlying hardware architecture as well. Sorry for the double post Rick, but I failed to send this to the list the first time... -- Jeff From rick_knight at rlknight.com Wed Aug 6 13:44:29 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:44:29 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: <4899FF1D.9030504@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > > >> The developer of the app I'm trying to use (Readerware) has sent me a >> copy of the comm.api and I've copied the library >> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >> into the proper places. When I try to run the application, I get this >> error... >> >> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >> /usr/lib/libSolarisSerialParallel.so: >> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >> little-endian (Possible cause: endianness mismatch) >> Caught java.lang.UnsatisfiedLinkError: >> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >> >> while loading driver com.sun.comm.SolarisDriver >> >> Is there a way around this error? >> > > What host OS are you running? From your original post it looks like 32 > bit Linux. > > The libSolarisSerialParallel.so file is for Sun Solaris and will vary > depending on the underlying hardware architecture as well. > > I'm running Kubuntu Linux (debian based). It's 32 bit. Rick Knight From jlar310 at gmail.com Wed Aug 6 15:33:23 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 16:33:23 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > I don't think Sun did binary libraries for Linux in the 2.0 version. Can someone with more historical experience than I confirm that? I recently tried to port a Comm API application from Solaris sparc to Linux x86 and likewise could not get my hands on the binary libraries. I eventually just re-wrote the code to use the gnu namespace packages and rxtx 2.1. What I don't understand is why your application vendor does not provide everything you need to run their software. FYI: I have librxtxParallel.so and librxtxSerial.so installed at JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is /usr/java/default which is actually a softlink to /usr/java/jre1.6.0_05. -- Jeff From defiantlew at yahoo.com.au Wed Aug 6 16:29:33 2008 From: defiantlew at yahoo.com.au (Lew L) Date: Thu, 7 Aug 2008 08:29:33 +1000 Subject: [Rxtx] Sun's Comm API Documentation References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> Message-ID: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> As a matter of interest is the Sun Comm API documentation available somewhere? I have tried the Sun site but it seems to have been removed. Unless I have missed the documentation for RXTX? I javadocced the RXTX source but information (to me) is minimal. Somewhere I got the impression that the Sun Comm API docs is, or was, compatible with RXTX, what is the best docs to use in conjuntion with RXTX and where may the be available? Cheers Lew From rick_knight at rlknight.com Wed Aug 6 17:18:33 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:18:33 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A3149.4050306@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff I'm not sure if I posted this here or not, but when I try to build RXTX from source I get this install error... make all-am make[1]: Entering directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' make[1]: Nothing to be done for `all-am'. make[1]: Leaving directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 Can you tell me how to get past this error and get RXTX built and installed? Thanks, Rick From bboyes at systronix.com Wed Aug 6 17:40:12 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Wed, 06 Aug 2008 17:40:12 -0600 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: At 16:29 08/06/2008, Lew L wrote: >As a matter of interest is the Sun Comm API documentation available >somewhere? I have tried the Sun site but it seems to have been removed. It's in the file we have posted, link in prev email (sorry, in a huge hurry right now). Javadocs definitely there. >Unless I have missed the documentation for RXTX? I javadocced the RXTX >source but information (to me) is minimal. >Somewhere I got the impression that the Sun Comm API docs is, or was, >compatible with RXTX, what is the best docs to use in conjuntion with RXTX >and where may the be available? Yeah, this is one of my concerns/beefs. There is little documentation for RXTX and it isn't just the same as javaxcomm. I would be willing to help out writing docs for RXTX! Yes really... esp if we can fix the Bluetooth issues. best regards Bruce >Cheers >Lew > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx ------- WWW.SYSTRONIX.COM ---------- Real embedded Java and much more +1-801-534-1017 Salt Lake City, USA From rick_knight at rlknight.com Wed Aug 6 17:54:08 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:54:08 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A39A0.2090309@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff, I would like for my vendor to switch to rxtx 2.1. It would make things much easier for me. I'm not sure why he's still using the javax compatible code. He's a small operation. Re-writing the code to use gnu namespace sounds like a major overhaul. Was it? Thanks, Rick From tjarvi at qbang.org Wed Aug 6 21:35:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:35:12 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: >> >>> Jeff wrote: >>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>>> >>>> >>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things > much easier for me. I'm not sure why he's still using the javax > compatible code. He's a small operation. Re-writing the code to use gnu > namespace sounds like a major overhaul. Was it? > Hi Jeff, The changes are fairly mechanical. Imports need to change and any explicite use of the namespace needs to change such as catching an exception. The following script was made for maintaining rxtx 2.0 but can apply to other needs. It is in the contrib dir with rxtx source. #!/bin/sh # Don't use! :) # # Sat, 03 May 2003 16:45:08 Modifications from J?rg Weule # Create a ed-cmd for the change of one pattern # case $1 in gnu) X=g/javax_comm/s+javax_comm+gnu_io+g ;; javax) X=g/gnu_io/s+gnu_io+javax_comm+g ;; *) echo;echo;echo From the top rxtx directory run;echo;echo -e \\t./ChangePackage.sh gnu;echo -e \\t\\tor;echo -e \\t./ChangePackage.sh javax;echo;echo; exit 0 ;; esac # # ed will be used to keep the owner and mode of the files unchanged. # We have run the ed-script for the characters '.' '/' as well. # "tr _ $D" do the change. # find . -type f -a -print | grep -v $0 | (while read F ; do ( echo $X; echo $X| tr _ /; echo $X| tr _ .; echo w; echo q ) | ed $F 2>&1 >/dev/null done ) # # Now we do little changes at the Makefiles. Hope that all we need. # find . -name Makefile\* -a -print | (while read F ; do cat < References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: On Thu, 7 Aug 2008, Lew L wrote: > As a matter of interest is the Sun Comm API documentation available > somewhere? I have tried the Sun site but it seems to have been removed. > > Unless I have missed the documentation for RXTX? I javadocced the RXTX > source but information (to me) is minimal. > Somewhere I got the impression that the Sun Comm API docs is, or was, > compatible with RXTX, what is the best docs to use in conjuntion with RXTX > and where may the be available? > Hi Lew, The documentation on Sun's website is accurate. The changes that are problematic in 3.0 are on the backside which rxtx used to plug into. http://java.sun.com/products/javacomm/reference/api/index.html CommPortIdentifier may have some minor differences (judging by the authors notes). -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Aug 6 21:46:08 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:46:08 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > If javax.comm.properties is properly installed and you are using a 2.0 version of Sun's commapi with rxtx 2.0, you should not see the library attempt to load libSolarisSerialParallel.so. Sun CommAPI 3.0 will not work with any version of rxtx as it is hard coded to use the shared library. See the INSTALL file with rxtx-2.0 source for more help with the properties file. -- Trent Jarvi tjarvi at qbang.org From jlar310 at gmail.com Thu Aug 7 06:32:06 2008 From: jlar310 at gmail.com (Jeff) Date: Thu, 7 Aug 2008 07:32:06 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > Jeff wrote: >> >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >> wrote: >> >>> >>> Jeff wrote: >>> >>>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>> wrote: >>>> >>>> >>>> >>>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things much > easier for me. I'm not sure why he's still using the javax compatible code. > He's a small operation. Re-writing the code to use gnu namespace sounds like > a major overhaul. Was it? I found it quite easy. In fact, in order to accommodate the transition, I actually separated all of the code that deals directly with the Comm API or RXTX into a helper class. The helper class was then coded to use reflection to determine which library was available and then instantiate the necessary objects. No direct imports of either library are used. The main application just needs to get it's hands on the IO streams and need not deal directly with the libraries. Other programs may not be so simple... But this doesn't really help you unless your vendor forks over the source code... -- Jeff From rick_knight at rlknight.com Thu Aug 7 09:47:12 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Thu, 07 Aug 2008 08:47:12 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: <489B1900.10108@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >>> wrote: >>> >>> >>>> Jeff wrote: >>>> >>>> >>>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>>> copy of the comm.api and I've copied the library >>>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>>> into the proper places. When I try to run the application, I get this >>>>>> error... >>>>>> >>>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>>> /usr/lib/libSolarisSerialParallel.so: >>>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>>> little-endian (Possible cause: endianness mismatch) >>>>>> Caught java.lang.UnsatisfiedLinkError: >>>>>> >>>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>>> >>>>>> while loading driver com.sun.comm.SolarisDriver >>>>>> >>>>>> Is there a way around this error? >>>>>> >>>>>> >>>>>> >>>>> What host OS are you running? From your original post it looks like 32 >>>>> bit Linux. >>>>> >>>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>>> depending on the underlying hardware architecture as well. >>>>> >>>>> >>>>> >>>>> >>>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>>> >>>> >>>> >>> I don't think Sun did binary libraries for Linux in the 2.0 version. >>> Can someone with more historical experience than I confirm that? >>> >>> I recently tried to port a Comm API application from Solaris sparc to >>> Linux x86 and likewise could not get my hands on the binary libraries. >>> I eventually just re-wrote the code to use the gnu namespace packages >>> and rxtx 2.1. >>> >>> What I don't understand is why your application vendor does not >>> provide everything you need to run their software. >>> >>> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >>> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >>> /usr/java/default which is actually a softlink to >>> /usr/java/jre1.6.0_05. >>> >>> >>> >> Jeff, >> >> I would like for my vendor to switch to rxtx 2.1. It would make things much >> easier for me. I'm not sure why he's still using the javax compatible code. >> He's a small operation. Re-writing the code to use gnu namespace sounds like >> a major overhaul. Was it? >> > > I found it quite easy. In fact, in order to accommodate the > transition, I actually separated all of the code that deals directly > with the Comm API or RXTX into a helper class. The helper class was > then coded to use reflection to determine which library was available > and then instantiate the necessary objects. No direct imports of > either library are used. The main application just needs to get it's > hands on the IO streams and need not deal directly with the libraries. > Other programs may not be so simple... > > But this doesn't really help you unless your vendor forks over the > source code... > > Jeff, This may not help me directly, but I'm going to forward this thread to the vendor. I think he'll be open to making things work. Thanks again, Rick Knight From agusmunioz at gmail.com Thu Aug 7 16:39:51 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Thu, 7 Aug 2008 19:39:51 -0300 Subject: [Rxtx] How to send ack? Message-ID: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Hi, I'm still learning about serial communication and I have some doubts. I've got this question about how to do the following thing in rxtx. I have this hardware that connect to a PC using a serial port. These hardware receives data from a telephone line, proccess it, and then send it forward to the serial port. I've used a program named wincomm that shows what information is send it through the serial port and I have the nex behaviour: The hardware has a buffer where all data is stored, that cannot be sent it through the seria port. The program reads the first data send it by the hardware, and keep reading the same data always. There is a button in the application that says enable Ack, and when I click, then the hardware start to send all the stored information, and all the information is shown. I write a class, using rxtx that reads the serial port, and the same thing happens, it remains reading the same (first) data all the time. And I thing something like the enable Ack I'm missing. How can I do this enable Ack from my java code using rxtx? Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080807/e0a0f9a1/attachment-0015.html From ajmas at sympatico.ca Thu Aug 7 18:26:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 7 Aug 2008 20:26:41 -0400 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: <4BF42297-81E2-4BB8-A89F-1D43588379AE@sympatico.ca> On 6-Aug-08, at 19:40 , Bruce Boyes wrote: >> Unless I have missed the documentation for RXTX? I javadocced the >> RXTX >> source but information (to me) is minimal. >> Somewhere I got the impression that the Sun Comm API docs is, or was, >> compatible with RXTX, what is the best docs to use in conjuntion >> with RXTX >> and where may the be available? > > Yeah, this is one of my concerns/beefs. There is little documentation > for RXTX and it isn't just the same as javaxcomm. > > I would be willing to help out writing docs for RXTX! Yes really... > esp if we can fix the Bluetooth issues. If you want to contribute documentation then the best place to do that is the wiki. If there is anything missing or that could be improved on then please do so. If there are any points that you would like to see improved, for which you don't have the knowledge then ask on the mailing list for a volunteer. Andre From florianmanschwetus at gmx.de Fri Aug 8 03:04:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Fri, 08 Aug 2008 11:04:14 +0200 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Message-ID: <489C0C0E.2020401@gmx.de> Agustin Mu?oz schrieb: > Hi, I'm still learning about serial communication and I have some > doubts. I've got this question about how to do the following thing in rxtx. > I have this hardware that connect to a PC using a serial port. These > hardware receives data from a telephone line, proccess it, and then send > it forward to the serial port. I've used a program named wincomm that > shows what information is send it through the serial port and I have the > nex behaviour: > > The hardware has a buffer where all data is stored, that cannot be sent > it through the seria port. > The program reads the first data send it by the hardware, and keep > reading the same data always. > There is a button in the application that says enable Ack, and when I > click, then the hardware start to send all the stored information, and > all the information is shown. > > I write a class, using rxtx that reads the serial port, and the same > thing happens, it remains reading the same (first) data all the time. > And I thing something like the enable Ack I'm missing. > How can I do this enable Ack from my java code using rxtx? Afaik, a look at man ascii reveals: Okt Dez Hex Char 006 6 06 ACK So, i hope this will do the job: send(6); florian > > Thanks in advance > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/5b4965f8/attachment-0015.bin From agusmunioz at gmail.com Fri Aug 8 16:31:00 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 19:31:00 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <489C0C0E.2020401@gmx.de> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> Message-ID: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Hi Florian, thanks for the answer. By send(6) you mean to get the port OutputStream and write a 6? I try that but it didn't work. Any suggestion? Thanks On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < florianmanschwetus at gmx.de> wrote: > Agustin Mu?oz schrieb: > > Hi, I'm still learning about serial communication and I have some doubts. >> I've got this question about how to do the following thing in rxtx. >> I have this hardware that connect to a PC using a serial port. These >> hardware receives data from a telephone line, proccess it, and then send it >> forward to the serial port. I've used a program named wincomm that shows >> what information is send it through the serial port and I have the nex >> behaviour: >> >> The hardware has a buffer where all data is stored, that cannot be sent >> it through the seria port. >> The program reads the first data send it by the hardware, and keep reading >> the same data always. >> There is a button in the application that says enable Ack, and when I >> click, then the hardware start to send all the stored information, and all >> the information is shown. >> >> I write a class, using rxtx that reads the serial port, and the same thing >> happens, it remains reading the same (first) data all the time. And I thing >> something like the enable Ack I'm missing. >> How can I do this enable Ack from my java code using rxtx? >> > Afaik, a look at man ascii reveals: > Okt Dez Hex Char > 006 6 06 ACK > So, i hope this will do the job: > send(6); > > florian > >> >> Thanks in advance >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/7f3fba42/attachment-0014.html From agusmunioz at gmail.com Fri Aug 8 18:39:27 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 21:39:27 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Message-ID: <988288430808081739x7f9e7889id82591d5a9e2b4f6@mail.gmail.com> Ok, Florian, it works!! my problem was that I've been sending, through the OutputStream, the bytes of 6 as a string: out.write("6".getBytes()); but then I realized that you can write an int on an OuptuStream, so I tried that and It works: out.write(6); Thank you for the guidance!! On Fri, Aug 8, 2008 at 7:31 PM, Agustin Mu?oz wrote: > Hi Florian, thanks for the answer. By send(6) you mean to get the port > OutputStream and write a 6? > > I try that but it didn't work. > > Any suggestion? > > Thanks > > > On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < > florianmanschwetus at gmx.de> wrote: > >> Agustin Mu?oz schrieb: >> >> Hi, I'm still learning about serial communication and I have some doubts. >>> I've got this question about how to do the following thing in rxtx. >>> I have this hardware that connect to a PC using a serial port. These >>> hardware receives data from a telephone line, proccess it, and then send it >>> forward to the serial port. I've used a program named wincomm that shows >>> what information is send it through the serial port and I have the nex >>> behaviour: >>> >>> The hardware has a buffer where all data is stored, that cannot be sent >>> it through the seria port. >>> The program reads the first data send it by the hardware, and keep >>> reading the same data always. >>> There is a button in the application that says enable Ack, and when I >>> click, then the hardware start to send all the stored information, and all >>> the information is shown. >>> >>> I write a class, using rxtx that reads the serial port, and the same >>> thing happens, it remains reading the same (first) data all the time. And I >>> thing something like the enable Ack I'm missing. >>> How can I do this enable Ack from my java code using rxtx? >>> >> Afaik, a look at man ascii reveals: >> Okt Dez Hex Char >> 006 6 06 ACK >> So, i hope this will do the job: >> send(6); >> >> florian >> >>> >>> Thanks in advance >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/b918ab3d/attachment-0014.html From florianmanschwetus at gmx.de Sat Aug 9 00:45:43 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Sat, 09 Aug 2008 08:45:43 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4899667C.6010706@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> Message-ID: <489D3D17.9090209@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >> Florian Manschwetus wrote: >>> Ok, sounds fine for the receiving problem. >>> But why i have to wait after each byte when sending a command squence? >>> (the for loop in send command) >> >> Hi Florian, >> I'd imagine you probably don't! You could send all bytes in one go and >> RXTX would send them. The problem is most probably the other end: >> perhaps it has a really small buffer, some non-standard UART, or a >> crazy timing issue. If you attach a terminal to your output and send >> all the bytes of a command in one go they should appear no problem. >> >> Regards, >> Michael Erskine. >> > correct with a terminal on the other end it works, my idea was that this > basic baud has some influence. Could some one explain what it is for? > > Florian To make it more clear, my problem is that i can't use: outputStream.write(byte[]); => Beamer doesn't understand the sequence. (mostly no answer when he answers then *001) when i use this construct instead: for (int i = 0; i < command.length; i++) { this.outputStream.write(command[i]); try { Thread.sleep(25); } catch (InterruptedException e) { // TODO Auto-generated catch block e.printStackTrace(); } } it works nearly reliable. So what could it be? This Basic Baud is what exactly? Florian -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080809/692304ee/attachment-0014.bin From tjarvi at qbang.org Sat Aug 9 16:37:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Aug 2008 16:37:19 -0600 (MDT) Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489D3D17.9090209@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> <489D3D17.9090209@gmx.de> Message-ID: On Sat, 9 Aug 2008, Florian Manschwetus wrote: > Florian Manschwetus schrieb: >> Michael Erskine schrieb: >>> Florian Manschwetus wrote: >>>> Ok, sounds fine for the receiving problem. >>>> But why i have to wait after each byte when sending a command squence? >>>> (the for loop in send command) >>> >>> Hi Florian, >>> I'd imagine you probably don't! You could send all bytes in one go and >>> RXTX would send them. The problem is most probably the other end: perhaps >>> it has a really small buffer, some non-standard UART, or a crazy timing >>> issue. If you attach a terminal to your output and send all the bytes of a >>> command in one go they should appear no problem. >>> >>> Regards, >>> Michael Erskine. >>> >> correct with a terminal on the other end it works, my idea was that this >> basic baud has some influence. Could some one explain what it is for? >> >> Florian > To make it more clear, > my problem is that i can't use: > outputStream.write(byte[]); > => Beamer doesn't understand the sequence. (mostly no answer when he answers > then *001) > > when i use this construct instead: > > for (int i = 0; i < command.length; i++) { > this.outputStream.write(command[i]); > try { > Thread.sleep(25); > } catch (InterruptedException e) { > // TODO Auto-generated catch block > e.printStackTrace(); > } > } > > it works nearly reliable. > > So what could it be? This Basic Baud is what exactly? > I suspect you are using the 'moon protocol' and don't know it. RXTX enables this by default. The buffer on the other end is first in first out while reading. If the buffer is full, the bits are hand carried to the moon and burried. Then if the other side reads a couple bytes, two more bytes go into the buffer followed by more moon protocol. The resulting array of bytes the other side reads may appear to be scrambled until you go to the moon, get the bits and insert them in the right place. Flow control can prevent the default moon protocol and throttles the communiation by almost writing a byte at a time as need be. Hardware flow control is preferable but software flow control should also work. Read and write can appear to hang if the other side is not connected. This is why we don't enable them all the time. If you can't use flow control, you have to take care with the moon protocol and give the other side time to read. That is what your slower version of write is doing. -- Trent Jarvi tjarvi at qbang.org From rxtx at allenjb.me.uk Mon Aug 11 08:06:36 2008 From: rxtx at allenjb.me.uk (AllenJB) Date: Mon, 11 Aug 2008 15:06:36 +0100 Subject: [Rxtx] Disabling EV_RXFLAG Message-ID: <48A0476C.2090800@allenjb.me.uk> Hi all, I'm working with a device which does not use an EvtChar and need to disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an event mask of FD 01 00 00. The reference software I have uses FB 00 00 00. With the rxtx mask I get framing errors which I believe are caused when the EvtChar is received. Is there currently a way with rxtx (I've using rxtx from Java) to disable EV_RXFLAG? If not from Java, where would I start if I wanted to turn the EV_RXFLAG option off in the C code? I've had a grep of the rxtx source code, but I can't see where EV_RXFLAG is being set. Thanks in advance, AllenJB From tjarvi at qbang.org Mon Aug 11 14:17:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Aug 2008 14:17:27 -0600 (MDT) Subject: [Rxtx] Disabling EV_RXFLAG In-Reply-To: <48A0476C.2090800@allenjb.me.uk> References: <48A0476C.2090800@allenjb.me.uk> Message-ID: On Mon, 11 Aug 2008, AllenJB wrote: > Hi all, > > I'm working with a device which does not use an EvtChar and need to > disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an > event mask of FD 01 00 00. The reference software I have uses FB 00 00 > 00. With the rxtx mask I get framing errors which I believe are caused > when the EvtChar is received. > > Is there currently a way with rxtx (I've using rxtx from Java) to > disable EV_RXFLAG? > > If not from Java, where would I start if I wanted to turn the EV_RXFLAG > option off in the C code? I've had a grep of the rxtx source code, but I > can't see where EV_RXFLAG is being set. > > Thanks in advance, > > AllenJB Hi Allen, I'd look at termios.c::tcsetattr() and termios.c::FillDCB() -- Trent Jarvi tjarvi at qbang.org From superdadusa at gmail.com Tue Aug 12 13:57:32 2008 From: superdadusa at gmail.com (John Choi) Date: Tue, 12 Aug 2008 13:57:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. Message-ID: Hi all, Just let you all know I just start to learn Java. I have download the serial comm package and the source code from open source communities.. I was able to verify with the given message string via serial monitor. when the given message string sends to the serial port then the character return added to the end of string by default if I use "Hello World" however if I changed to something else other than "Hello, World" there is no character return add to the end of string. I thing the library download from rxtx.org has implemented for the special strings. I can do like "login\n" in the string message to make character return but I don't want to add this individual custom character for each command return in every static message string I send, Can any who have done this might help me? Basically, something like this,, Write and add function to the program write a command, Reads the respond from a serial device.. Function handles multiple messages, Write: "com open" Read: Welcome to my world" expected Write: "admin" Read: Password?, expected Write: "admin" Read: you are successfully login terminal, expected. And I need to add a separate function handler handles a character return add to the each command above. If anyone can help this I can do the reset? Thank you in advance, John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0010.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SerialIO.java Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0010.pl From Steffen.DETTMER at ingenico.com Wed Aug 13 02:16:38 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 13 Aug 2008 10:16:38 +0200 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: References: Message-ID: <20080813081638.GA25412@elberon.bln.de.ingenico.com> * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > I can do like "login\n" in the string message to make character > return but I don't want to add this individual custom character > for each command return in every static message string I send, and why not?! > Can any who have done this might help me? what's about with writing a small wrapper function adding the carriage return? However, this would be slow, because either you call write two times (very bad) or the string needs to be copied, \n appended and written (since you are using Java Performance probably isn't so critical). Personally I would write `"login\n"' and `username + "\n"' etc., because since it is part of the command it should be part of the command definition string. > Basically, something like this,, Write and add function to the program write > a command, Reads the respond from a serial device.. correctly reading a `line' is more difficult. If you cannot make assumptions about timeouts and/or you need to have low delay, you need to read byte wise. If you need to save CPU resources you might need to add some buffering layer that you can read byte-wise but that is reading blockwise with some small timeout (lets say for serial lines something around byte transmission time times three or so). > /* > * To change this template, choose Tools | Templates > * and open the template in the editor. > */ :) > package joliba; > > /** > * > * @author root > */ :) > // derived from SUN's examples in the javax.comm package > import java.io.*; > import java.util.*; > //import javax.comm.*; // for SUN's serial/parallel port libraries > import gnu.io.*; // for rxtxSerial library > > public class SerialIO implements Runnable, SerialPortEventListener { > static CommPortIdentifier portId; > static CommPortIdentifier saveportId; > static Enumeration portList; > InputStream inputStream; > SerialPort serialPort; > Thread readThread; You need a thread for your synchronous RPC-style protocol? > static String messageString = "Hello, world!"; > static OutputStream outputStream; > static boolean outputBufferEmptyFlag = false; > > public static void main(String[] args) { > boolean portFound = false; > String defaultPort; > > // determine the name of the serial port on several operating systems > String osname = System.getProperty("os.name","").toLowerCase(); > if ( osname.startsWith("windows") ) { > // windows > defaultPort = "COM1"; > } else if (osname.startsWith("linux")) { > // linux > defaultPort = "/dev/ttyS0"; > } else if ( osname.startsWith("mac") ) { > // mac > defaultPort = "????"; > } else { > System.out.println("Sorry, your operating system is not supported"); > return; > } Is such a construction recommended? Isn't there some abstraction (like COM1 working on any platform)? [...] > try { > // activate the OUTPUT_BUFFER_EMPTY notifier > serialPort.notifyOnOutputEmpty(true); > } catch (Exception e) { > System.out.println("Error setting event notification"); > System.out.println(e.toString()); > System.exit(-1); > } I doubt that -1 is defined, probably some 127 or so would be the result, maybe better simply `throw e'? > public void writetoport() { > System.out.println("Writing \""+messageString+"\" to "+serialPort.getName()); > try { > // write string to serial port > outputStream.write(messageString.getBytes()); > } catch (IOException e) {} > } maybe something like /** * Writes the given output string and an additional carriage * return to the current outputStream. */ public void writeStringToPort( /** The output string (without CR). */ String output ) throws IOException { String outputLine = output + "\n"; outputStream.write(outputLine.getBytes()); } ? > > public SerialIO() { > // initalize serial port > try { > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > } catch (PortInUseException e) {} if the port is in use, you continue? Wonder that this works in Java, I would assume serialPort beeing uninitialized which AFAIK is an error in Java. > try { > inputStream = serialPort.getInputStream(); > } catch (IOException e) {} > > try { > serialPort.addEventListener(this); > } catch (TooManyListenersException e) {} > > // activate the DATA_AVAILABLE notifier > serialPort.notifyOnDataAvailable(true); > > try { > // set port parameters > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > } catch (UnsupportedCommOperationException e) {} > > // start the read thread > readThread = new Thread(this); > readThread.start(); > > } I think in all those exception cases you can abort, because it is unlikely that ignoring those errors allow a successful continuation, so in this case maybe it would be better to add a throw clause to the method. > public void run() { > // first thing in the thread, we initialize the write operation > initwritetoport(); > try { > while (true) { > // write string to port, the serialEvent will read it > writetoport(); > Thread.sleep(1000); > } > } catch (InterruptedException e) {} > } Does this make sense? Your `SimpleReadApp' writes one and the same string each second? > public void serialEvent(SerialPortEvent event) { > switch (event.getEventType()) { > case SerialPortEvent.BI: > case SerialPortEvent.OE: > case SerialPortEvent.FE: > case SerialPortEvent.PE: > case SerialPortEvent.CD: > case SerialPortEvent.CTS: > case SerialPortEvent.DSR: > case SerialPortEvent.RI: > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > break; > case SerialPortEvent.DATA_AVAILABLE: > // we get here if data has been received > byte[] readBuffer = new byte[20]; > try { > // read data > while (inputStream.available() > 0) { > int numBytes = inputStream.read(readBuffer); > } > // print data > String result = new String(readBuffer); > System.out.println("Read: "+result); > } catch (IOException e) {} I doubt that this is correct. I would assume you will get a 20 bytes result always, if more bytes would be available they would be printed in a second line but if less bytes are read I'd assume that the buffer/result contains zero bytes from implicite readBuffer contents initialisation (zero is no string terminator in Java AFAIK). > break; > } > } > } oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From florianmanschwetus at gmx.de Wed Aug 13 06:09:31 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 13 Aug 2008 14:09:31 +0200 Subject: [Rxtx] someone has seen such errors? Message-ID: <48A2CEFB.90007@gmx.de> I mean my communication mostly works, but it is far from perfect could this be the reason? Florian Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/949b9947/attachment-0010.bin From superdadusa at gmail.com Wed Aug 13 08:40:32 2008 From: superdadusa at gmail.com (John Choi) Date: Wed, 13 Aug 2008 08:40:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: <20080813081638.GA25412@elberon.bln.de.ingenico.com> References: <20080813081638.GA25412@elberon.bln.de.ingenico.com> Message-ID: Thank you so much Steffen and I will try that suggestion. John On 8/13/08, Steffen DETTMER wrote: > > * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > > I can do like "login\n" in the string message to make character > > return but I don't want to add this individual custom character > > for each command return in every static message string I send, > > and why not?! > > > Can any who have done this might help me? > > what's about with writing a small wrapper function adding the > carriage return? > However, this would be slow, because either you call write two > times (very bad) or the string needs to be copied, \n appended > and written (since you are using Java Performance probably isn't > so critical). > > Personally I would write `"login\n"' and `username + "\n"' etc., > because since it is part of the command it should be part of the > command definition string. > > > Basically, something like this,, Write and add function to the program > write > > a command, Reads the respond from a serial device.. > > correctly reading a `line' is more difficult. If you cannot make > assumptions about timeouts and/or you need to have low delay, you > need to read byte wise. If you need to save CPU resources you > might need to add some buffering layer that you can read > byte-wise but that is reading blockwise with some small timeout > (lets say for serial lines something around byte transmission > time times three or so). > > > /* > > * To change this template, choose Tools | Templates > > * and open the template in the editor. > > */ > > :) > > > package joliba; > > > > /** > > * > > * @author root > > */ > > :) > > > // derived from SUN's examples in the javax.comm package > > import java.io.*; > > import java.util.*; > > //import javax.comm.*; // for SUN's serial/parallel port libraries > > import gnu.io.*; // for rxtxSerial library > > > > public class SerialIO implements Runnable, SerialPortEventListener { > > static CommPortIdentifier portId; > > static CommPortIdentifier saveportId; > > static Enumeration portList; > > InputStream inputStream; > > SerialPort serialPort; > > Thread readThread; > > You need a thread for your synchronous RPC-style protocol? > > > static String messageString = "Hello, world!"; > > static OutputStream outputStream; > > static boolean outputBufferEmptyFlag = false; > > > > public static void main(String[] args) { > > boolean portFound = false; > > String defaultPort; > > > > // determine the name of the serial port on several operating > systems > > String osname = System.getProperty("os.name","").toLowerCase(); > > if ( osname.startsWith("windows") ) { > > // windows > > defaultPort = "COM1"; > > } else if (osname.startsWith("linux")) { > > // linux > > defaultPort = "/dev/ttyS0"; > > } else if ( osname.startsWith("mac") ) { > > // mac > > defaultPort = "????"; > > } else { > > System.out.println("Sorry, your operating system is not > supported"); > > return; > > } > > Is such a construction recommended? Isn't there some abstraction > (like COM1 working on any platform)? > > [...] > > try { > > // activate the OUTPUT_BUFFER_EMPTY notifier > > serialPort.notifyOnOutputEmpty(true); > > } catch (Exception e) { > > System.out.println("Error setting event notification"); > > System.out.println(e.toString()); > > System.exit(-1); > > } > > I doubt that -1 is defined, probably some 127 or so would be the > result, maybe better simply `throw e'? > > > public void writetoport() { > > System.out.println("Writing \""+messageString+"\" to > "+serialPort.getName()); > > try { > > // write string to serial port > > outputStream.write(messageString.getBytes()); > > } catch (IOException e) {} > > } > > maybe something like > > /** > * Writes the given output string and an additional carriage > * return to the current outputStream. > */ > public void > writeStringToPort( > /** The output string (without CR). */ > String output > ) throws IOException > { > String outputLine = output + "\n"; > outputStream.write(outputLine.getBytes()); > } > > ? > > > > > public SerialIO() { > > // initalize serial port > > try { > > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > > } catch (PortInUseException e) {} > > if the port is in use, you continue? Wonder that this works in > Java, I would assume serialPort beeing uninitialized which AFAIK > is an error in Java. > > > try { > > inputStream = serialPort.getInputStream(); > > } catch (IOException e) {} > > > > try { > > serialPort.addEventListener(this); > > } catch (TooManyListenersException e) {} > > > > // activate the DATA_AVAILABLE notifier > > serialPort.notifyOnDataAvailable(true); > > > > try { > > // set port parameters > > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > } catch (UnsupportedCommOperationException e) {} > > > > // start the read thread > > readThread = new Thread(this); > > readThread.start(); > > > > } > > I think in all those exception cases you can abort, because it is > unlikely that ignoring those errors allow a successful > continuation, so in this case maybe it would be better to add a > throw clause to the method. > > > public void run() { > > // first thing in the thread, we initialize the write operation > > initwritetoport(); > > try { > > while (true) { > > // write string to port, the serialEvent will read it > > writetoport(); > > Thread.sleep(1000); > > } > > } catch (InterruptedException e) {} > > } > > Does this make sense? Your `SimpleReadApp' writes one and the > same string each second? > > > public void serialEvent(SerialPortEvent event) { > > switch (event.getEventType()) { > > case SerialPortEvent.BI: > > case SerialPortEvent.OE: > > case SerialPortEvent.FE: > > case SerialPortEvent.PE: > > case SerialPortEvent.CD: > > case SerialPortEvent.CTS: > > case SerialPortEvent.DSR: > > case SerialPortEvent.RI: > > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > > break; > > case SerialPortEvent.DATA_AVAILABLE: > > // we get here if data has been received > > byte[] readBuffer = new byte[20]; > > try { > > // read data > > while (inputStream.available() > 0) { > > int numBytes = inputStream.read(readBuffer); > > } > > // print data > > String result = new String(readBuffer); > > System.out.println("Read: "+result); > > } catch (IOException e) {} > > I doubt that this is correct. I would assume you will get a 20 > bytes result always, if more bytes would be available they would > be printed in a second line but if less bytes are read I'd assume > that the buffer/result contains zero bytes from implicite > readBuffer contents initialisation (zero is no string terminator > in Java AFAIK). > > > break; > > } > > } > > } > > oki, > > Steffen > > About Ingenico Throughout the world businesses rely on Ingenico for secure > and expedient electronic transaction acceptance. Ingenico products leverage > proven technology, established standards and unparalleled ergonomics to > provide optimal reliability, versatility and usability. This comprehensive > range of products is complemented by a global array of services and > partnerships, enabling businesses in a number of vertical sectors to accept > transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged > information. If you are not the addressee or authorized to receive this for > the addressee, you must not use, copy, disclose or take any action based on > this message or any information herein. If you have received this message in > error, please advise the sender immediately by reply e-mail and delete this > message. Thank you for your cooperation. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/73c4135c/attachment-0009.html From ajmas at sympatico.ca Sat Aug 16 07:15:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 09:15:41 -0400 Subject: [Rxtx] someone has seen such errors? In-Reply-To: <48A2CEFB.90007@gmx.de> References: <48A2CEFB.90007@gmx.de> Message-ID: <43B5E8DA-1D93-4D90-809B-AAF35FF724C5@sympatico.ca> On 13-Aug-08, at 08:09 , Florian Manschwetus wrote: > I mean my communication mostly works, but it is far from perfect > could this be the reason? > > Florian > > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control Judging by the error messages this looks related to the driver you are using. Do a search for the following string with you favourite search engine, it should turn up a few hits: ftdi_set_termios FAILED to set databits/stopbits/parity Andre From ajmas at sympatico.ca Sat Aug 16 19:12:04 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 21:12:04 -0400 Subject: [Rxtx] Using SerialPortEvent? Message-ID: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Hi, Could someone tell me how I should be using the SerialPortEvent? Am I meant to be waiting for data and then simply reading from the inputstream? If this is the case why no just block on an inputstream read? Andr? From tjarvi at qbang.org Sat Aug 16 19:41:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 16 Aug 2008 19:41:13 -0600 (MDT) Subject: [Rxtx] Using SerialPortEvent? In-Reply-To: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> References: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Message-ID: On Sat, 16 Aug 2008, Andre-John Mas wrote: > Hi, > > Could someone tell me how I should be using the SerialPortEvent? Am I > meant to be waiting for data and then simply reading from the > inputstream? If this is the case why no just block on an inputstream > read? > Polling for data is fine also. It really depends upon what you are trying to do. For instance, if you require x bytes before reading, you can start polling after data is available. If you read on the same thread as your GUI and are waiting for data in a read, the results may be less than desirable. Java programming is 'usually' event driven rather than polling based. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sat Aug 16 20:10:39 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 22:10:39 -0400 Subject: [Rxtx] Using SerialPortEvent? In-Reply-To: References: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Message-ID: <3E495D4C-BB28-4845-A6AB-984C9A826BDF@sympatico.ca> On 16-Aug-08, at 21:41 , Trent Jarvi wrote: > On Sat, 16 Aug 2008, Andre-John Mas wrote: > >> Hi, >> >> Could someone tell me how I should be using the SerialPortEvent? Am I >> meant to be waiting for data and then simply reading from the >> inputstream? If this is the case why no just block on an inputstream >> read? >> > > Polling for data is fine also. It really depends upon what you are > trying to do. For instance, if you require x bytes before reading, > you can start polling after data is available. If you read on the > same thread as your GUI and are waiting for data in a read, the > results may be less than desirable. > > Java programming is 'usually' event driven rather than polling based. Sounds good. I thought I would use this opportunity to provide a event based version of the TwoWaySerialComm example. Could you just validate it before I add it to the Wiki: package ajmas74.experimental; import gnu.io.CommPort; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; import gnu.io.SerialPortEvent; import gnu.io.SerialPortEventListener; import java.io.IOException; import java.io.InputStream; import java.io.OutputStream; /** * This version of the TwoWaySerialComm example makes use of the * SerialPortEventListener to avoid polling. * * @author ajmas * */ public class TwoWaySerialComm { public TwoWaySerialComm() { super(); } void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { CommPort commPort = portIdentifier.open(this.getClass().getName(),2000); if ( commPort instanceof SerialPort ) { SerialPort serialPort = (SerialPort) commPort; serialPort .setSerialPortParams (57600 ,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); (new Thread(new SerialWriter(out))).start(); serialPort.addEventListener(new SerialReader(in)); } else { System.out.println("Error: Only serial ports are handled by this example."); } } } /** * Handles the input coming from the serial port. A new line character * is treated as the end of a block in this example. */ public static class SerialReader implements SerialPortEventListener { private InputStream in; private byte[] buffer = new byte[1024]; public SerialReader ( InputStream in ) { this.in = in; } public void serialEvent(SerialPortEvent arg0) { int data; try { int len = 0; while ( ( data = in.read()) > -1 ) { if ( data != '\n' ) { break; } buffer[len++] = (byte) data; } System.out.print(new String(buffer,0,len)); } catch ( IOException e ) { e.printStackTrace(); System.exit(-1); } } } /** */ public static class SerialWriter implements Runnable { OutputStream out; public SerialWriter ( OutputStream out ) { this.out = out; } public void run () { try { int c = 0; while ( ( c = System.in.read()) > -1 ) { this.out.write(c); } } catch ( IOException e ) { e.printStackTrace(); System.exit(-1); } } } public static void main ( String[] args ) { try { (new TwoWaySerialComm()).connect("COM3"); } catch ( Exception e ) { e.printStackTrace(); } } } From lfarkas at lfarkas.org Tue Aug 19 07:32:59 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Tue, 19 Aug 2008 15:32:59 +0200 Subject: [Rxtx] JNI or CNI Message-ID: <48AACB8B.9060606@lfarkas.org> hi, what is the current recommended way to rxtx on linux JNI or it's better to use CNI? is the CNI version fully functional and the same level as the JNI? i currently try to make a rhel/centos/fedora rpm for rxtx but has many problems with the standard dir structure. yours. -- Levente "Si vis pacem para bellum!" From lfarkas at lfarkas.org Tue Aug 19 08:47:34 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Tue, 19 Aug 2008 16:47:34 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel Message-ID: <48AADD06.7040809@lfarkas.org> hi, newer or not so newer linux kernel do not contain the UTS_RELEASE so the current rxtx is not compile on the latest kernels. even if it's commented out in the cvs configure there are other places. i attcahed a patch which fix it (or at least doesn't cause error at non-debug build). ps. is there any plan to the new 2.1-8 release in the near future? there are many changes (at least the license change in all file and in this case create a diff is very difficult)? the latest release more then 2 years old:-( -- Levente "Si vis pacem para bellum!" -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-2.1-uts.patch Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080819/ab5d38ac/attachment-0002.pl From ajmas at sympatico.ca Tue Aug 19 16:21:53 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 19 Aug 2008 18:21:53 -0400 Subject: [Rxtx] Event based example Message-ID: <24735BFB-B088-4B84-8173-FE98DF63B12F@sympatico.ca> Hi, I have just posted an example of using SerialPortEventListener in the Wiki: http://rxtx.qbang.org/wiki/index.php/Event_Based_Two_Way_Communication If you see any issues please could you let me know, or makes the changes. Andre From Martin.Oberhuber at windriver.com Fri Aug 22 04:02:24 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 22 Aug 2008 12:02:24 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <48AADD06.7040809@lfarkas.org> References: <48AADD06.7040809@lfarkas.org> Message-ID: <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> Farkas, there are indeed efforts to get a new RXTX release out the door. Your experience as a package maintainer would likely be helpful during these efforts, since I'd think it makes sense to keep the patches minimal that you must make to have the source compile in your environment. What are the things that you find problematic, apart from the UTS thing that you have mentioned before? What is the timing that you have in mind for your package? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Farkas Levente > Sent: Tuesday, August 19, 2008 4:48 PM > To: rxtx at qbang.org > Subject: [Rxtx] UTS_RELEASE not defined in newer kernel > > hi, > newer or not so newer linux kernel do not contain the > UTS_RELEASE so the > current rxtx is not compile on the latest kernels. even if it's > commented out in the cvs configure there are other places. > i attcahed a patch which fix it (or at least doesn't cause error at > non-debug build). > > ps. is there any plan to the new 2.1-8 release in the near > future? there > are many changes (at least the license change in all file and in this > case create a diff is very difficult)? the latest release more then 2 > years old:-( > > -- > Levente "Si vis pacem para bellum!" > From lfarkas at lfarkas.org Fri Aug 22 04:36:26 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Fri, 22 Aug 2008 12:36:26 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> References: <48AADD06.7040809@lfarkas.org> <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> Message-ID: <48AE96AA.6090505@lfarkas.org> hi, the packages already build for fedora-9 and centos-5 and here: http://www.lfarkas.org/linux/packages/ what i've to patch, the UTS, the configure script, but it's already fixed in the cvs (in another way) and the loadlibrary. the reasons for last one can be found here: https://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_files_that_use_JNI after we test it i'd like to add these packages to fedora and epel main repository (that's why it's be useful a new release after 2 years:-) imho versions are cheap and why not just release 2.1-8? the real code changes are minimal and if something critical bug found still can release 2.1-9:-) ps. and would be better to use simple number for version like 2.1-7 rather then 2.1-7v2. Oberhuber, Martin wrote: > Farkas, > > there are indeed efforts to get a new RXTX release out the > door. Your experience as a package maintainer would likely > be helpful during these efforts, since I'd think it makes > sense to keep the patches minimal that you must make to > have the source compile in your environment. > > What are the things that you find problematic, apart from > the UTS thing that you have mentioned before? > > What is the timing that you have in mind for your package? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >> On Behalf Of Farkas Levente >> Sent: Tuesday, August 19, 2008 4:48 PM >> To: rxtx at qbang.org >> Subject: [Rxtx] UTS_RELEASE not defined in newer kernel >> >> hi, >> newer or not so newer linux kernel do not contain the >> UTS_RELEASE so the >> current rxtx is not compile on the latest kernels. even if it's >> commented out in the cvs configure there are other places. >> i attcahed a patch which fix it (or at least doesn't cause error at >> non-debug build). >> >> ps. is there any plan to the new 2.1-8 release in the near >> future? there >> are many changes (at least the license change in all file and in this >> case create a diff is very difficult)? the latest release more then 2 >> years old:-( >> >> -- >> Levente "Si vis pacem para bellum!" >> -- Levente "Si vis pacem para bellum!" From rick_knight at rlknight.com Mon Aug 4 13:25:10 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Mon, 04 Aug 2008 12:25:10 -0700 Subject: [Rxtx] Sun's Comm API? Message-ID: <48975796.4010600@rlknight.com> I have an application that requires the javax compatible version of RXTX and Sun's comm api. I've been able to download and extract the version of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api anywhere. Can someone tell me where I can find it? Or maybe send me a copy? Also, when I try to build RXTX, configure and make complete successfully but make install failes with this error libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 I've never come accross this error before. How can I get past it? Thanks, Rick From bboyes at systronix.com Mon Aug 4 19:10:01 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:10:01 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48975796.4010600@rlknight.com> References: <48975796.4010600@rlknight.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/cb9c6167/attachment-0019.html From bboyes at systronix.com Mon Aug 4 19:12:37 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:12:37 -0600 Subject: [Rxtx] Towards an RXTX release - CSR BT/USB chipset In-Reply-To: <488FB7E7.8000802@gmail.com> References: <460801A4097E3D4CA04CC64EE648584806C56CF0@ism-mail03.corp.ad.wrs.com> <13557-75390@sneakemail.com> <20980-23424@sneakemail.com> <488FB7E7.8000802@gmail.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/52236088/attachment-0019.html From tjarvi at qbang.org Mon Aug 4 19:42:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 19:42:21 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: On Mon, 4 Aug 2008, Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: > I have an application that requires the javax compatible > version of RXTX > and Sun's comm api. I've been able to download and extract > the version > of RXTX that I need (2.0-7pre2) but I can't find Sun's camm > api > anywhere. Can someone tell me where I can find it? Or maybe > send me a > > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm port > support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have just > a ZIP with only the .class JAR file - no source or docs), has a readme > with these comments: > > This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release.? The 2.0.3 release itself is > no longer distributed.? comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project.? The RxTx project (http://www.rxtx.org ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org) was opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support.? Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins.? Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > ? > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > I hope that is helpful! > It would be nice to work with Sun to resolve those longstanding issues. But it may not be practical unless the process goes as fast and painless as the grandfathering of commapi did. Another option may be the old kaffe extensions that moved to gnu classpathx. These don't have the native libraries but should provide the 2.0 interface and the javax.comm.properties mechansim for SPI. http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Mon Aug 4 20:23:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Mon, 04 Aug 2008 20:23:57 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4897B9BD.5070809@ergotech.com> Has there been any work/would it be possible, to layer a javacomm look-alike on top of the GNU code? The goal is not to move the javax code forward, but to emulate the "legacy" javax packages for people who still need this. Jim Trent Jarvi wrote: > On Mon, 4 Aug 2008, Bruce Boyes wrote: > >> At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible >> version of RXTX >> and Sun's comm api. I've been able to download and extract >> the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm >> api >> anywhere. Can someone tell me where I can find it? Or maybe >> send me a >> >> >> javaxcomm has had a sort of on-again off-again history. The windoze >> version has been languishing for years (literally) but there are newer >> versions for other OS's. >> >> We try to keep links on one of our help pages current: >> http://www.practicalembeddedjava.com/tools/javatools_list.html >> which gets you to here: >> http://java.sun.com/products/javacomm/ >> where it says in fact they no longer even support Windows and Mac: >> "Implementations of the API are currently available for Solaris SPARC, >> Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so >> someone could support it. But I guess that's part of the reason RXTX >> exists! >> >> So one of Sun's own products, SunSPOT, has to use RXTX to get comm port >> support. >> >> The version we use is 2.0 from 11/15/1998. I have posted it on our >> website, which is within the terms of the license agreement contained >> therein (as I understand it). >> >> The last version of javaxcomm for Windows, 2.0.3, (for which I have just >> a ZIP with only the .class JAR file - no source or docs), has a readme >> with these comments: >> >> This distribution contains the comm.jar file original part >> of the COMMAPI 2.0.3 release. The 2.0.3 release itself is >> no longer distributed. comm.jar, which contains the comm >> API java class files (eg. Sun's binary implementation of the >> interface classes), is being made available, unsupported, >> with no obligation to fix bugs, at the request of the RXTX >> project. The RxTx project (http://www.rxtx.org ), uses the >> comm.jar class files, but provides their own native library >> components to provide support for other platforms. >> >> The 2.0.3 comm.jar is being provided in this way because >> as of COMMAPI 3.x, the java binary implementation forked and >> became incompatible with the RxTx project's native code. >> Due to the lack of a clear business case, and to resource >> constraints, no additional resources are being >> provided to provide an alternative engineering solution >> at the time of writing. >> >> RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: >> >> Ultimately the COMMAPI would be better served if a Java >> Community Process JSR (http://www.jcp.org) was opened and >> the COMMAPI was rearchitected to provide a more pluggable >> framework to improve cross-platform support. Such an >> architecture would embody a better defined and better >> documented SPI interface, including a way for comm. ports >> to be revealed to the client application through the API >> via platform-aware plugins. Similarly, native code used >> to access comm port in general could be handled more >> flexibly using a plugin model, whereby on any platform, >> multiple native modules could be in use simultaneously. >> >> Since there are now various ways serial ports can be implemented >> and accessed, modular comm. port JNI native libraries would be >> of benefit insofar as removing the burden of over-generalization >> from any single native component, or inversely, by relieving the >> implicit constraint that comm. drivers be accessed only via a >> monolithic mechanism, such as the UNIX vnode interface. >> >> paul.klissner at sun.com >> 6/10/06 >> >> I hope that is helpful! >> > > It would be nice to work with Sun to resolve those longstanding issues. > But it may not be practical unless the process goes as fast and painless > as the grandfathering of commapi did. > > Another option may be the old kaffe extensions that moved to gnu > classpathx. These don't have the native libraries but should provide > the 2.0 interface and the javax.comm.properties mechansim for SPI. > > http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Mon Aug 4 21:09:15 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 21:09:15 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? Message-ID: Hi Jim, I will not step into the javax.comm namespace without Sun's explicite permission. I fully understand the pain point you are trying to address. In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm Linux) - which remains an integral part of rxtx. At the time it was a win for Sun and rxtx. The Sun commapi license is/was fairly clear that rxtx should not step into that namespace. It made sense as Sun was active in that space and rxtx may go into another namespace - it was an experiment in working with Sun. This may sound silly looking at something that happened almost 10 years ago. In a community of respect which Sun helped create, there is no question about what to do. I hope eventually Sun will step up and do a right thing too. I agree that this is hurting the API more than helping it. There are also questions about how to replace the API in the long term which includes HID support which isn't going well so far. Others that can't even look at Sun's javax.comm today and can look at Kaffe's contribution to classpathx can easily work around such restrictions. On Mon, 4 Aug 2008, Jim Redman wrote: > Has there been any work/would it be possible, to layer a javacomm > look-alike on top of the GNU code? > > The goal is not to move the javax code forward, but to emulate the > "legacy" javax packages for people who still need this. > > Jim > > Trent Jarvi wrote: >> >> It would be nice to work with Sun to resolve those longstanding issues. >> But it may not be practical unless the process goes as fast and painless >> as the grandfathering of commapi did. >> >> Another option may be the old kaffe extensions that moved to gnu >> classpathx. These don't have the native libraries but should provide >> the 2.0 interface and the javax.comm.properties mechansim for SPI. >> >> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From florianmanschwetus at gmx.de Tue Aug 5 05:04:46 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 13:04:46 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: References: <48971C1F.9020806@gmx.de> Message-ID: <489833CE.1040801@gmx.de> Just look at sendCommand in this method I have to place a Thread.sleep(20) after each byte send to get working. Even the event based receive doesn't work fine but this could be may stupidness. The specifikation document (it is on the last pages of the manual) for the beamer could be found on: http://www.optoma.co.uk/support.aspx Florian Manschwetus Trent Jarvi schrieb: > > Hi Florian > > Sorry for the top post in advance. I worry you may not see my answer > under all your code :) > > I have not received this email before. This is 500k of code which I > don't have time to read. I can spend about 5 min on each hobby email > and still get to work in the morning. I have a couple suggestions for > how to get an answer. > > First, cut out your comments and extra code so you can demonstrate the > question (I might even glance and see what is wrong then). Don't go for > a working final product. Isolate the problem using a simple program and > then ask with that as an example. If I did what you just did, I'd have > to post 3/4 of a million lines of code :) > > Second, join the rxtx mail-list and ask there. This will give you 100x > more eyes. I'll also read and try to follow. > > -- > taj > > > > On Mon, 4 Aug 2008, Florian Manschwetus wrote: > >> It could be that my university account is blocked by filters so >> resending from here. >> >> >> Topic is to control Optoma HD80 beamer using rs232 serial chat. >> This code is able to detect power state and switch the beamer on / off. >> connected is the beamer using a digitus usb 2.0 serial adapter with an >> FT232 USB-Serial adapter the systems architecture is amd64. >> >> Please take a look in the sendCommand routine i have to place theire >> those Thread.sleep to get it working. >> Now the question is this correct or is there a better way to get this >> working correctly? >> >> In the javadoc coming with the install i found this: >> setBaudBase >> >> public boolean setBaudBase(int BaudBase) >> throws UnsupportedCommOperationException, >> java.io.IOException >> >> Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 >> before using. >> >> could this explain the error? >> I attached my java source and the protocol description for the beamer >> (available on vendor website). >> >> thx, >> Florian Manschwetus >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: TestRS232.java Type: text/x-java Size: 9143 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0038.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0039.bin From michael.erskine at ketech.com Tue Aug 5 05:53:49 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Tue, 5 Aug 2008 12:53:49 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489833CE.1040801@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> > Just look at sendCommand in this method I have to place a > Thread.sleep(20) after each byte send to get working. Even the event > based receive doesn't work fine but this could be may stupidness. Hi Florian, Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. Regards, Michael Erskine. From florianmanschwetus at gmx.de Tue Aug 5 07:28:15 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:28:15 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> Message-ID: <4898556F.8000208@gmx.de> Michael Erskine schrieb: >> Just look at sendCommand in this method I have to place a >> Thread.sleep(20) after each byte send to get working. Even the event >> based receive doesn't work fine but this could be may stupidness. > > Hi Florian, > > Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. > > Regards, > Michael Erskine. > Ok, sounds fine for the receiving problem. But why i have to wait after each byte when sending a command squence? (the for loop in send command) Florian > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/284f350c/attachment-0018.bin From florianmanschwetus at gmx.de Tue Aug 5 07:44:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:44:14 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <4898592E.2020908@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >>> Just look at sendCommand in this method I have to place a >>> Thread.sleep(20) after each byte send to get working. Even the event >>> based receive doesn't work fine but this could be may stupidness. >> >> Hi Florian, >> >> Yes, naturally you'll have to wait for a response from the other end. >> Why not wait for notification from the event thread perhaps using a >> BlockingDeque rather than your LinkedList. Generally I >> try to decouple all input and output streams: in your case your >> application is operating synchronously like the "expect" program >> (http://expect.nist.gov/) so waits (or timeouts) will need to be >> factored in. >> >> Regards, >> Michael Erskine. >> > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) > > Florian Furthermore there is this basic baud with this confusing javadoc entry: public boolean setBaudBase(int BaudBase) throws UnsupportedCommOperationException, java.io.IOException Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 before using. maybe this could explain something Florian >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/006c7425/attachment-0018.bin From jredman at ergotech.com Tue Aug 5 09:13:36 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 05 Aug 2008 09:13:36 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: Message-ID: <48986E20.3060104@ergotech.com> Trent, So two issues: 1) Technically I'm still not sure how easy/practical a layer would be. The problems are always classes like listeners, and wrapping returns of gnu.io classes. I really see it as a "delegate" type of concept. Any thoughts or ideas of the practicality of this approach? The idea is not to modify RXTX. 2) Javax. The javax namespace does seem to be in widespread use outside of Sun (the same is true for the java namespace). The classpath extensions, or some other location, should be interested in a JavaComm implementation even if it does have dependencies on RXTX. Would you have any philosophical objection to an approach like that? Of course, I suspect it might be better if someone with that authority at Sun would admit that the javax namespace is already in the wild and that there is no problem with it being used within RXTX. Jim Trent Jarvi wrote: > Hi Jim, > > I will not step into the javax.comm namespace without Sun's explicite > permission. I fully understand the pain point you are trying to address. > > In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm > Linux) - which remains an integral part of rxtx. At the time it was a win for > Sun and rxtx. > > The Sun commapi license is/was fairly clear that rxtx should not step into that > namespace. It made sense as Sun was active in that space and rxtx may go into > another namespace - it was an experiment in working with Sun. > > This may sound silly looking at something that happened almost 10 years ago. > In a community of respect which Sun helped create, there is no question about > what to do. I hope eventually Sun will step up and do a right thing too. > > I agree that this is hurting the API more than helping it. There are also > questions about how to replace the API in the long term which includes HID > support which isn't going well so far. > > Others that can't even look at Sun's javax.comm today and can look at Kaffe's > contribution to classpathx can easily work around such restrictions. > > On Mon, 4 Aug 2008, Jim Redman wrote: > >> Has there been any work/would it be possible, to layer a javacomm >> look-alike on top of the GNU code? >> >> The goal is not to move the javax code forward, but to emulate the >> "legacy" javax packages for people who still need this. >> >> Jim >> >> Trent Jarvi wrote: >>> It would be nice to work with Sun to resolve those longstanding issues. >>> But it may not be practical unless the process goes as fast and painless >>> as the grandfathering of commapi did. >>> >>> Another option may be the old kaffe extensions that moved to gnu >>> classpathx. These don't have the native libraries but should provide >>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>> >>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From sandeep at genevasoftech.com Tue Aug 5 11:18:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Tue, 05 Aug 2008 22:48:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <48988B6C.5080409@genevasoftech.com> Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. *-- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/ad20f1cb/attachment-0018.html From Martin.Oberhuber at windriver.com Tue Aug 5 13:30:17 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Tue, 5 Aug 2008 21:30:17 +0200 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Sandeep, shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on Sol7 but I've successfully run it on Sol9 and Sol10. Or is your request really about a native 64bit variant? I'm afraid that then you're out of luck since I think that quite a bit of RXTX is not yet ready for 64 bit. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Sandeep Kumar K Sent: Tuesday, August 05, 2008 7:19 PM To: rxtx at qbang.org Subject: [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so for Solaris 9 Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. -- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/81b7f988/attachment-0018.html From tjarvi at qbang.org Tue Aug 5 22:38:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 22:38:34 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 5 Aug 2008, Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built > on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid that > then > you're out of luck since I think that quite a bit of RXTX is not yet > ready > for 64 bit. > While rxtx-2.1-7 probably has problems, The CVS code should be OK for 64 bit Solaris. If it isn't, let me know and I'll find which patch is missing. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Aug 5 23:13:00 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 23:13:00 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48986E20.3060104@ergotech.com> References: <48986E20.3060104@ergotech.com> Message-ID: On Tue, 5 Aug 2008, Jim Redman wrote: > Trent, > > So two issues: > > 1) Technically I'm still not sure how easy/practical a layer would be. The > problems are always classes like listeners, and wrapping returns of gnu.io > classes. I really see it as a "delegate" type of concept. Any thoughts or > ideas of the practicality of this approach? The idea is not to modify RXTX. I have not put too much thought into this. I assume you want what rxtx 2.0 provided to tie into javax.comm implementations. More classes could be added to rxtx 2.1-7 for SPI support. Maintaining rxtx-2.0 could also be handed to someone if they like. > > 2) Javax. The javax namespace does seem to be in widespread use outside of > Sun (the same is true for the java namespace). The classpath extensions, or > some other location, should be interested in a JavaComm implementation even > if it does have dependencies on RXTX. Would you have any philosophical > objection to an approach like that? > No problems. Classpathx would be a possible place to do it. I'd suggest thinking twice about what this involves in practical terms. You would be wanting to revive the 2.0 API while Sun is at 3.0 and grandfathering the JSR. This undermines the main reason (established api) for using the javax.comm namespace and does not leave such a project in a good position. The only win I see here is maintaining support for applications that can't migrate namespaces. Not that that isn't important. At some point it is going to be less work to just edit the bytecode :) Such a javax.comm effort would also be signing up new projects that decided to use the work up for concerns they probably will not understand or expect. That probably isn't a good path to facilitate for new projects at this time. We will put a good faith effort to work well with others but keep in mind the project has limited bandwidth for such efforts. > Of course, I suspect it might be better if someone with that authority at Sun > would admit that the javax namespace is already in the wild and that there is > no problem with it being used within RXTX. > > Jim > > Trent Jarvi wrote: >> Hi Jim, >> >> I will not step into the javax.comm namespace without Sun's explicite >> permission. I fully understand the pain point you are trying to address. >> >> In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java >> Comm Linux) - which remains an integral part of rxtx. At the time it was a >> win for Sun and rxtx. >> >> The Sun commapi license is/was fairly clear that rxtx should not step into >> that namespace. It made sense as Sun was active in that space and rxtx may >> go into another namespace - it was an experiment in working with Sun. >> >> This may sound silly looking at something that happened almost 10 years >> ago. In a community of respect which Sun helped create, there is no >> question about what to do. I hope eventually Sun will step up and do a >> right thing too. >> >> I agree that this is hurting the API more than helping it. There are also >> questions about how to replace the API in the long term which includes HID >> support which isn't going well so far. >> >> Others that can't even look at Sun's javax.comm today and can look at >> Kaffe's contribution to classpathx can easily work around such >> restrictions. >> >> On Mon, 4 Aug 2008, Jim Redman wrote: >> >>> Has there been any work/would it be possible, to layer a javacomm >>> look-alike on top of the GNU code? >>> >>> The goal is not to move the javax code forward, but to emulate the >>> "legacy" javax packages for people who still need this. >>> >>> Jim >>> >>> Trent Jarvi wrote: >>>> It would be nice to work with Sun to resolve those longstanding issues. >>>> But it may not be practical unless the process goes as fast and painless >>>> as the grandfathering of commapi did. >>>> >>>> Another option may be the old kaffe extensions that moved to gnu >>>> classpathx. These don't have the native libraries but should provide >>>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>>> >>>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From sandeep at genevasoftech.com Wed Aug 6 00:03:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Wed, 06 Aug 2008 11:33:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: <48993EB8.30107@genevasoftech.com> Thank you Mr. Martin for your suggestion. The native file which is given in rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am getting the following error . Any suggestions to solve this issue. I am using Solaris SPARC 64 bit machine. ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) thrown while loading gnu.io.RXTXCommDriver Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(Unknown Source) at java.lang.ClassLoader.loadLibrary(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) at com.ReadFromModem.main(ReadFromModem.java:84) * * *Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid > that then > you're out of luck since I think that quite a bit of RXTX is not yet ready > for 64 bit. > > Cheers, > -- > *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > ------------------------------------------------------------------------ > *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On > Behalf Of *Sandeep Kumar K > *Sent:* Tuesday, August 05, 2008 7:19 PM > *To:* rxtx at qbang.org > *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so > for Solaris 9 > > Hi, > > Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 > bit machine. The librxtxSerial.so given in website is for Solaris 8. > > *-- > > Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/1e920343/attachment-0018.html From tjarvi at qbang.org Wed Aug 6 00:21:42 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 00:21:42 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <48993EB8.30107@genevasoftech.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> <48993EB8.30107@genevasoftech.com> Message-ID: Hi Sandeep You may be out of luck unless you can compile the 2.1 src in CVS (requires gnu make and gcc). But you could try the ToyBox(R)(TM) which is a collection of WiLdLy untested cross compiled 2.1-7 binaries covering everything from the ibm z series to embeded arm/ppc. To give an idea how poorly these are tested, I don't even know if z series machines have a serial port. ftp://www.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Solaris They should at least match the binary types. Actually, I think if you use the rxtx jar from CVS with that file, it should 'work' as the fix for 64 bits was in java not the native code. You could just cd rxtx*/src; javac *.java then jar -cf RXTXcomm.jar `find -name \*.class` to create the hybrid which will complain about version information a bit. On Wed, 6 Aug 2008, Sandeep Kumar K wrote: > Thank you Mr. Martin for your suggestion. The native file which is given in > rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am > getting the following error . > Any suggestions to solve this issue. > I am using Solaris SPARC 64 bit machine. > > ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar > java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 > (Possible cause: architecture word > width mismatch) thrown while loading gnu.io.RXTXCommDriver > Exception in thread "main" java.lang.UnsatisfiedLinkError: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF > class: ELFCLASS64 (Possible cause: > architecture word width mismatch) > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(Unknown Source) > at java.lang.ClassLoader.loadLibrary(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > at com.ReadFromModem.main(ReadFromModem.java:84) > > * > * > > *Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > > > Oberhuber, Martin wrote: >> Sandeep, >> shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse >> variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on >> Sol7 but I've successfully run it on Sol9 and Sol10. >> Or is your request really about a native 64bit variant? I'm afraid that >> then >> you're out of luck since I think that quite a bit of RXTX is not yet ready >> for 64 bit. >> Cheers, >> -- >> *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> ------------------------------------------------------------------------ >> *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On >> Behalf Of *Sandeep Kumar K >> *Sent:* Tuesday, August 05, 2008 7:19 PM >> *To:* rxtx at qbang.org >> *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so >> for Solaris 9 >> >> Hi, >> >> Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 >> bit machine. The librxtxSerial.so given in website is for Solaris 8. >> >> *-- >> Thanks & Regards >> >> Sandeep Kumar K >> Sr. Software Engineer >> Geneva Software Technologies >> Whitefield, Bangalore >> Mob : 9880193454* >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> From michael.erskine at ketech.com Wed Aug 6 01:39:28 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 6 Aug 2008 08:39:28 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Florian Manschwetus wrote: > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) Hi Florian, I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. Regards, Michael Erskine. From florianmanschwetus at gmx.de Wed Aug 6 02:53:16 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 06 Aug 2008 10:53:16 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Message-ID: <4899667C.6010706@gmx.de> Michael Erskine schrieb: > Florian Manschwetus wrote: >> Ok, sounds fine for the receiving problem. >> But why i have to wait after each byte when sending a command squence? >> (the for loop in send command) > > Hi Florian, > I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. > > Regards, > Michael Erskine. > correct with a terminal on the other end it works, my idea was that this basic baud has some influence. Could some one explain what it is for? Florian > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/c2b4fa84/attachment-0018.bin From rick_knight at rlknight.com Wed Aug 6 13:01:07 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:01:07 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F4F3.3020707@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > I have an application (Readerware) that uses RXTX with Javax to access the serial port. This used to work fine under previous Linux' and Java, but something has changed, I assume with Java itself , that is causing the application to fail with a link error. The application is not able to find librxtxSerialParallel.so. RXTX supplies librxtxSerial.so and librxtxParallel.so, but not librxtxSerialParallel.so. Where can I get librxtxSerialParallel.so, or do I need it? Is something else causing the lib to not be found? Thanks, Rick Knight From rick_knight at rlknight.com Wed Aug 6 13:17:55 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:17:55 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F8E3.5060400@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Thanks for the reply. The developer of the app I'm trying to use (Readerware) has sent me a copy of the comm.api and I've copied the library (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar into the proper places. When I try to run the application, I get this error... Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: /usr/lib/libSolarisSerialParallel.so: /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not little-endian (Possible cause: endianness mismatch) Caught java.lang.UnsatisfiedLinkError: com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I while loading driver com.sun.comm.SolarisDriver Is there a way around this error? Thanks again, Rick Knight From jlar310 at gmail.com Wed Aug 6 13:37:42 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 14:37:42 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899F8E3.5060400@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > The developer of the app I'm trying to use (Readerware) has sent me a > copy of the comm.api and I've copied the library > (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar > into the proper places. When I try to run the application, I get this > error... > > Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: > /usr/lib/libSolarisSerialParallel.so: > /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not > little-endian (Possible cause: endianness mismatch) > Caught java.lang.UnsatisfiedLinkError: > com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I > > while loading driver com.sun.comm.SolarisDriver > > Is there a way around this error? What host OS are you running? From your original post it looks like 32 bit Linux. The libSolarisSerialParallel.so file is for Sun Solaris and will vary depending on the underlying hardware architecture as well. Sorry for the double post Rick, but I failed to send this to the list the first time... -- Jeff From rick_knight at rlknight.com Wed Aug 6 13:44:29 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:44:29 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: <4899FF1D.9030504@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > > >> The developer of the app I'm trying to use (Readerware) has sent me a >> copy of the comm.api and I've copied the library >> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >> into the proper places. When I try to run the application, I get this >> error... >> >> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >> /usr/lib/libSolarisSerialParallel.so: >> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >> little-endian (Possible cause: endianness mismatch) >> Caught java.lang.UnsatisfiedLinkError: >> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >> >> while loading driver com.sun.comm.SolarisDriver >> >> Is there a way around this error? >> > > What host OS are you running? From your original post it looks like 32 > bit Linux. > > The libSolarisSerialParallel.so file is for Sun Solaris and will vary > depending on the underlying hardware architecture as well. > > I'm running Kubuntu Linux (debian based). It's 32 bit. Rick Knight From jlar310 at gmail.com Wed Aug 6 15:33:23 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 16:33:23 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > I don't think Sun did binary libraries for Linux in the 2.0 version. Can someone with more historical experience than I confirm that? I recently tried to port a Comm API application from Solaris sparc to Linux x86 and likewise could not get my hands on the binary libraries. I eventually just re-wrote the code to use the gnu namespace packages and rxtx 2.1. What I don't understand is why your application vendor does not provide everything you need to run their software. FYI: I have librxtxParallel.so and librxtxSerial.so installed at JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is /usr/java/default which is actually a softlink to /usr/java/jre1.6.0_05. -- Jeff From defiantlew at yahoo.com.au Wed Aug 6 16:29:33 2008 From: defiantlew at yahoo.com.au (Lew L) Date: Thu, 7 Aug 2008 08:29:33 +1000 Subject: [Rxtx] Sun's Comm API Documentation References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> Message-ID: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> As a matter of interest is the Sun Comm API documentation available somewhere? I have tried the Sun site but it seems to have been removed. Unless I have missed the documentation for RXTX? I javadocced the RXTX source but information (to me) is minimal. Somewhere I got the impression that the Sun Comm API docs is, or was, compatible with RXTX, what is the best docs to use in conjuntion with RXTX and where may the be available? Cheers Lew From rick_knight at rlknight.com Wed Aug 6 17:18:33 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:18:33 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A3149.4050306@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff I'm not sure if I posted this here or not, but when I try to build RXTX from source I get this install error... make all-am make[1]: Entering directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' make[1]: Nothing to be done for `all-am'. make[1]: Leaving directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 Can you tell me how to get past this error and get RXTX built and installed? Thanks, Rick From bboyes at systronix.com Wed Aug 6 17:40:12 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Wed, 06 Aug 2008 17:40:12 -0600 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: At 16:29 08/06/2008, Lew L wrote: >As a matter of interest is the Sun Comm API documentation available >somewhere? I have tried the Sun site but it seems to have been removed. It's in the file we have posted, link in prev email (sorry, in a huge hurry right now). Javadocs definitely there. >Unless I have missed the documentation for RXTX? I javadocced the RXTX >source but information (to me) is minimal. >Somewhere I got the impression that the Sun Comm API docs is, or was, >compatible with RXTX, what is the best docs to use in conjuntion with RXTX >and where may the be available? Yeah, this is one of my concerns/beefs. There is little documentation for RXTX and it isn't just the same as javaxcomm. I would be willing to help out writing docs for RXTX! Yes really... esp if we can fix the Bluetooth issues. best regards Bruce >Cheers >Lew > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx ------- WWW.SYSTRONIX.COM ---------- Real embedded Java and much more +1-801-534-1017 Salt Lake City, USA From rick_knight at rlknight.com Wed Aug 6 17:54:08 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:54:08 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A39A0.2090309@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff, I would like for my vendor to switch to rxtx 2.1. It would make things much easier for me. I'm not sure why he's still using the javax compatible code. He's a small operation. Re-writing the code to use gnu namespace sounds like a major overhaul. Was it? Thanks, Rick From tjarvi at qbang.org Wed Aug 6 21:35:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:35:12 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: >> >>> Jeff wrote: >>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>>> >>>> >>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things > much easier for me. I'm not sure why he's still using the javax > compatible code. He's a small operation. Re-writing the code to use gnu > namespace sounds like a major overhaul. Was it? > Hi Jeff, The changes are fairly mechanical. Imports need to change and any explicite use of the namespace needs to change such as catching an exception. The following script was made for maintaining rxtx 2.0 but can apply to other needs. It is in the contrib dir with rxtx source. #!/bin/sh # Don't use! :) # # Sat, 03 May 2003 16:45:08 Modifications from J?rg Weule # Create a ed-cmd for the change of one pattern # case $1 in gnu) X=g/javax_comm/s+javax_comm+gnu_io+g ;; javax) X=g/gnu_io/s+gnu_io+javax_comm+g ;; *) echo;echo;echo From the top rxtx directory run;echo;echo -e \\t./ChangePackage.sh gnu;echo -e \\t\\tor;echo -e \\t./ChangePackage.sh javax;echo;echo; exit 0 ;; esac # # ed will be used to keep the owner and mode of the files unchanged. # We have run the ed-script for the characters '.' '/' as well. # "tr _ $D" do the change. # find . -type f -a -print | grep -v $0 | (while read F ; do ( echo $X; echo $X| tr _ /; echo $X| tr _ .; echo w; echo q ) | ed $F 2>&1 >/dev/null done ) # # Now we do little changes at the Makefiles. Hope that all we need. # find . -name Makefile\* -a -print | (while read F ; do cat < References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: On Thu, 7 Aug 2008, Lew L wrote: > As a matter of interest is the Sun Comm API documentation available > somewhere? I have tried the Sun site but it seems to have been removed. > > Unless I have missed the documentation for RXTX? I javadocced the RXTX > source but information (to me) is minimal. > Somewhere I got the impression that the Sun Comm API docs is, or was, > compatible with RXTX, what is the best docs to use in conjuntion with RXTX > and where may the be available? > Hi Lew, The documentation on Sun's website is accurate. The changes that are problematic in 3.0 are on the backside which rxtx used to plug into. http://java.sun.com/products/javacomm/reference/api/index.html CommPortIdentifier may have some minor differences (judging by the authors notes). -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Aug 6 21:46:08 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:46:08 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > If javax.comm.properties is properly installed and you are using a 2.0 version of Sun's commapi with rxtx 2.0, you should not see the library attempt to load libSolarisSerialParallel.so. Sun CommAPI 3.0 will not work with any version of rxtx as it is hard coded to use the shared library. See the INSTALL file with rxtx-2.0 source for more help with the properties file. -- Trent Jarvi tjarvi at qbang.org From jlar310 at gmail.com Thu Aug 7 06:32:06 2008 From: jlar310 at gmail.com (Jeff) Date: Thu, 7 Aug 2008 07:32:06 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > Jeff wrote: >> >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >> wrote: >> >>> >>> Jeff wrote: >>> >>>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>> wrote: >>>> >>>> >>>> >>>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things much > easier for me. I'm not sure why he's still using the javax compatible code. > He's a small operation. Re-writing the code to use gnu namespace sounds like > a major overhaul. Was it? I found it quite easy. In fact, in order to accommodate the transition, I actually separated all of the code that deals directly with the Comm API or RXTX into a helper class. The helper class was then coded to use reflection to determine which library was available and then instantiate the necessary objects. No direct imports of either library are used. The main application just needs to get it's hands on the IO streams and need not deal directly with the libraries. Other programs may not be so simple... But this doesn't really help you unless your vendor forks over the source code... -- Jeff From rick_knight at rlknight.com Thu Aug 7 09:47:12 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Thu, 07 Aug 2008 08:47:12 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: <489B1900.10108@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >>> wrote: >>> >>> >>>> Jeff wrote: >>>> >>>> >>>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>>> copy of the comm.api and I've copied the library >>>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>>> into the proper places. When I try to run the application, I get this >>>>>> error... >>>>>> >>>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>>> /usr/lib/libSolarisSerialParallel.so: >>>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>>> little-endian (Possible cause: endianness mismatch) >>>>>> Caught java.lang.UnsatisfiedLinkError: >>>>>> >>>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>>> >>>>>> while loading driver com.sun.comm.SolarisDriver >>>>>> >>>>>> Is there a way around this error? >>>>>> >>>>>> >>>>>> >>>>> What host OS are you running? From your original post it looks like 32 >>>>> bit Linux. >>>>> >>>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>>> depending on the underlying hardware architecture as well. >>>>> >>>>> >>>>> >>>>> >>>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>>> >>>> >>>> >>> I don't think Sun did binary libraries for Linux in the 2.0 version. >>> Can someone with more historical experience than I confirm that? >>> >>> I recently tried to port a Comm API application from Solaris sparc to >>> Linux x86 and likewise could not get my hands on the binary libraries. >>> I eventually just re-wrote the code to use the gnu namespace packages >>> and rxtx 2.1. >>> >>> What I don't understand is why your application vendor does not >>> provide everything you need to run their software. >>> >>> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >>> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >>> /usr/java/default which is actually a softlink to >>> /usr/java/jre1.6.0_05. >>> >>> >>> >> Jeff, >> >> I would like for my vendor to switch to rxtx 2.1. It would make things much >> easier for me. I'm not sure why he's still using the javax compatible code. >> He's a small operation. Re-writing the code to use gnu namespace sounds like >> a major overhaul. Was it? >> > > I found it quite easy. In fact, in order to accommodate the > transition, I actually separated all of the code that deals directly > with the Comm API or RXTX into a helper class. The helper class was > then coded to use reflection to determine which library was available > and then instantiate the necessary objects. No direct imports of > either library are used. The main application just needs to get it's > hands on the IO streams and need not deal directly with the libraries. > Other programs may not be so simple... > > But this doesn't really help you unless your vendor forks over the > source code... > > Jeff, This may not help me directly, but I'm going to forward this thread to the vendor. I think he'll be open to making things work. Thanks again, Rick Knight From agusmunioz at gmail.com Thu Aug 7 16:39:51 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Thu, 7 Aug 2008 19:39:51 -0300 Subject: [Rxtx] How to send ack? Message-ID: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Hi, I'm still learning about serial communication and I have some doubts. I've got this question about how to do the following thing in rxtx. I have this hardware that connect to a PC using a serial port. These hardware receives data from a telephone line, proccess it, and then send it forward to the serial port. I've used a program named wincomm that shows what information is send it through the serial port and I have the nex behaviour: The hardware has a buffer where all data is stored, that cannot be sent it through the seria port. The program reads the first data send it by the hardware, and keep reading the same data always. There is a button in the application that says enable Ack, and when I click, then the hardware start to send all the stored information, and all the information is shown. I write a class, using rxtx that reads the serial port, and the same thing happens, it remains reading the same (first) data all the time. And I thing something like the enable Ack I'm missing. How can I do this enable Ack from my java code using rxtx? Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080807/e0a0f9a1/attachment-0016.html From ajmas at sympatico.ca Thu Aug 7 18:26:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 7 Aug 2008 20:26:41 -0400 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: <4BF42297-81E2-4BB8-A89F-1D43588379AE@sympatico.ca> On 6-Aug-08, at 19:40 , Bruce Boyes wrote: >> Unless I have missed the documentation for RXTX? I javadocced the >> RXTX >> source but information (to me) is minimal. >> Somewhere I got the impression that the Sun Comm API docs is, or was, >> compatible with RXTX, what is the best docs to use in conjuntion >> with RXTX >> and where may the be available? > > Yeah, this is one of my concerns/beefs. There is little documentation > for RXTX and it isn't just the same as javaxcomm. > > I would be willing to help out writing docs for RXTX! Yes really... > esp if we can fix the Bluetooth issues. If you want to contribute documentation then the best place to do that is the wiki. If there is anything missing or that could be improved on then please do so. If there are any points that you would like to see improved, for which you don't have the knowledge then ask on the mailing list for a volunteer. Andre From florianmanschwetus at gmx.de Fri Aug 8 03:04:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Fri, 08 Aug 2008 11:04:14 +0200 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Message-ID: <489C0C0E.2020401@gmx.de> Agustin Mu?oz schrieb: > Hi, I'm still learning about serial communication and I have some > doubts. I've got this question about how to do the following thing in rxtx. > I have this hardware that connect to a PC using a serial port. These > hardware receives data from a telephone line, proccess it, and then send > it forward to the serial port. I've used a program named wincomm that > shows what information is send it through the serial port and I have the > nex behaviour: > > The hardware has a buffer where all data is stored, that cannot be sent > it through the seria port. > The program reads the first data send it by the hardware, and keep > reading the same data always. > There is a button in the application that says enable Ack, and when I > click, then the hardware start to send all the stored information, and > all the information is shown. > > I write a class, using rxtx that reads the serial port, and the same > thing happens, it remains reading the same (first) data all the time. > And I thing something like the enable Ack I'm missing. > How can I do this enable Ack from my java code using rxtx? Afaik, a look at man ascii reveals: Okt Dez Hex Char 006 6 06 ACK So, i hope this will do the job: send(6); florian > > Thanks in advance > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/5b4965f8/attachment-0016.bin From agusmunioz at gmail.com Fri Aug 8 16:31:00 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 19:31:00 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <489C0C0E.2020401@gmx.de> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> Message-ID: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Hi Florian, thanks for the answer. By send(6) you mean to get the port OutputStream and write a 6? I try that but it didn't work. Any suggestion? Thanks On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < florianmanschwetus at gmx.de> wrote: > Agustin Mu?oz schrieb: > > Hi, I'm still learning about serial communication and I have some doubts. >> I've got this question about how to do the following thing in rxtx. >> I have this hardware that connect to a PC using a serial port. These >> hardware receives data from a telephone line, proccess it, and then send it >> forward to the serial port. I've used a program named wincomm that shows >> what information is send it through the serial port and I have the nex >> behaviour: >> >> The hardware has a buffer where all data is stored, that cannot be sent >> it through the seria port. >> The program reads the first data send it by the hardware, and keep reading >> the same data always. >> There is a button in the application that says enable Ack, and when I >> click, then the hardware start to send all the stored information, and all >> the information is shown. >> >> I write a class, using rxtx that reads the serial port, and the same thing >> happens, it remains reading the same (first) data all the time. And I thing >> something like the enable Ack I'm missing. >> How can I do this enable Ack from my java code using rxtx? >> > Afaik, a look at man ascii reveals: > Okt Dez Hex Char > 006 6 06 ACK > So, i hope this will do the job: > send(6); > > florian > >> >> Thanks in advance >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/7f3fba42/attachment-0015.html From agusmunioz at gmail.com Fri Aug 8 18:39:27 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 21:39:27 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Message-ID: <988288430808081739x7f9e7889id82591d5a9e2b4f6@mail.gmail.com> Ok, Florian, it works!! my problem was that I've been sending, through the OutputStream, the bytes of 6 as a string: out.write("6".getBytes()); but then I realized that you can write an int on an OuptuStream, so I tried that and It works: out.write(6); Thank you for the guidance!! On Fri, Aug 8, 2008 at 7:31 PM, Agustin Mu?oz wrote: > Hi Florian, thanks for the answer. By send(6) you mean to get the port > OutputStream and write a 6? > > I try that but it didn't work. > > Any suggestion? > > Thanks > > > On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < > florianmanschwetus at gmx.de> wrote: > >> Agustin Mu?oz schrieb: >> >> Hi, I'm still learning about serial communication and I have some doubts. >>> I've got this question about how to do the following thing in rxtx. >>> I have this hardware that connect to a PC using a serial port. These >>> hardware receives data from a telephone line, proccess it, and then send it >>> forward to the serial port. I've used a program named wincomm that shows >>> what information is send it through the serial port and I have the nex >>> behaviour: >>> >>> The hardware has a buffer where all data is stored, that cannot be sent >>> it through the seria port. >>> The program reads the first data send it by the hardware, and keep >>> reading the same data always. >>> There is a button in the application that says enable Ack, and when I >>> click, then the hardware start to send all the stored information, and all >>> the information is shown. >>> >>> I write a class, using rxtx that reads the serial port, and the same >>> thing happens, it remains reading the same (first) data all the time. And I >>> thing something like the enable Ack I'm missing. >>> How can I do this enable Ack from my java code using rxtx? >>> >> Afaik, a look at man ascii reveals: >> Okt Dez Hex Char >> 006 6 06 ACK >> So, i hope this will do the job: >> send(6); >> >> florian >> >>> >>> Thanks in advance >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/b918ab3d/attachment-0015.html From florianmanschwetus at gmx.de Sat Aug 9 00:45:43 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Sat, 09 Aug 2008 08:45:43 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4899667C.6010706@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> Message-ID: <489D3D17.9090209@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >> Florian Manschwetus wrote: >>> Ok, sounds fine for the receiving problem. >>> But why i have to wait after each byte when sending a command squence? >>> (the for loop in send command) >> >> Hi Florian, >> I'd imagine you probably don't! You could send all bytes in one go and >> RXTX would send them. The problem is most probably the other end: >> perhaps it has a really small buffer, some non-standard UART, or a >> crazy timing issue. If you attach a terminal to your output and send >> all the bytes of a command in one go they should appear no problem. >> >> Regards, >> Michael Erskine. >> > correct with a terminal on the other end it works, my idea was that this > basic baud has some influence. Could some one explain what it is for? > > Florian To make it more clear, my problem is that i can't use: outputStream.write(byte[]); => Beamer doesn't understand the sequence. (mostly no answer when he answers then *001) when i use this construct instead: for (int i = 0; i < command.length; i++) { this.outputStream.write(command[i]); try { Thread.sleep(25); } catch (InterruptedException e) { // TODO Auto-generated catch block e.printStackTrace(); } } it works nearly reliable. So what could it be? This Basic Baud is what exactly? Florian -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080809/692304ee/attachment-0015.bin From tjarvi at qbang.org Sat Aug 9 16:37:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Aug 2008 16:37:19 -0600 (MDT) Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489D3D17.9090209@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> <489D3D17.9090209@gmx.de> Message-ID: On Sat, 9 Aug 2008, Florian Manschwetus wrote: > Florian Manschwetus schrieb: >> Michael Erskine schrieb: >>> Florian Manschwetus wrote: >>>> Ok, sounds fine for the receiving problem. >>>> But why i have to wait after each byte when sending a command squence? >>>> (the for loop in send command) >>> >>> Hi Florian, >>> I'd imagine you probably don't! You could send all bytes in one go and >>> RXTX would send them. The problem is most probably the other end: perhaps >>> it has a really small buffer, some non-standard UART, or a crazy timing >>> issue. If you attach a terminal to your output and send all the bytes of a >>> command in one go they should appear no problem. >>> >>> Regards, >>> Michael Erskine. >>> >> correct with a terminal on the other end it works, my idea was that this >> basic baud has some influence. Could some one explain what it is for? >> >> Florian > To make it more clear, > my problem is that i can't use: > outputStream.write(byte[]); > => Beamer doesn't understand the sequence. (mostly no answer when he answers > then *001) > > when i use this construct instead: > > for (int i = 0; i < command.length; i++) { > this.outputStream.write(command[i]); > try { > Thread.sleep(25); > } catch (InterruptedException e) { > // TODO Auto-generated catch block > e.printStackTrace(); > } > } > > it works nearly reliable. > > So what could it be? This Basic Baud is what exactly? > I suspect you are using the 'moon protocol' and don't know it. RXTX enables this by default. The buffer on the other end is first in first out while reading. If the buffer is full, the bits are hand carried to the moon and burried. Then if the other side reads a couple bytes, two more bytes go into the buffer followed by more moon protocol. The resulting array of bytes the other side reads may appear to be scrambled until you go to the moon, get the bits and insert them in the right place. Flow control can prevent the default moon protocol and throttles the communiation by almost writing a byte at a time as need be. Hardware flow control is preferable but software flow control should also work. Read and write can appear to hang if the other side is not connected. This is why we don't enable them all the time. If you can't use flow control, you have to take care with the moon protocol and give the other side time to read. That is what your slower version of write is doing. -- Trent Jarvi tjarvi at qbang.org From rxtx at allenjb.me.uk Mon Aug 11 08:06:36 2008 From: rxtx at allenjb.me.uk (AllenJB) Date: Mon, 11 Aug 2008 15:06:36 +0100 Subject: [Rxtx] Disabling EV_RXFLAG Message-ID: <48A0476C.2090800@allenjb.me.uk> Hi all, I'm working with a device which does not use an EvtChar and need to disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an event mask of FD 01 00 00. The reference software I have uses FB 00 00 00. With the rxtx mask I get framing errors which I believe are caused when the EvtChar is received. Is there currently a way with rxtx (I've using rxtx from Java) to disable EV_RXFLAG? If not from Java, where would I start if I wanted to turn the EV_RXFLAG option off in the C code? I've had a grep of the rxtx source code, but I can't see where EV_RXFLAG is being set. Thanks in advance, AllenJB From tjarvi at qbang.org Mon Aug 11 14:17:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Aug 2008 14:17:27 -0600 (MDT) Subject: [Rxtx] Disabling EV_RXFLAG In-Reply-To: <48A0476C.2090800@allenjb.me.uk> References: <48A0476C.2090800@allenjb.me.uk> Message-ID: On Mon, 11 Aug 2008, AllenJB wrote: > Hi all, > > I'm working with a device which does not use an EvtChar and need to > disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an > event mask of FD 01 00 00. The reference software I have uses FB 00 00 > 00. With the rxtx mask I get framing errors which I believe are caused > when the EvtChar is received. > > Is there currently a way with rxtx (I've using rxtx from Java) to > disable EV_RXFLAG? > > If not from Java, where would I start if I wanted to turn the EV_RXFLAG > option off in the C code? I've had a grep of the rxtx source code, but I > can't see where EV_RXFLAG is being set. > > Thanks in advance, > > AllenJB Hi Allen, I'd look at termios.c::tcsetattr() and termios.c::FillDCB() -- Trent Jarvi tjarvi at qbang.org From superdadusa at gmail.com Tue Aug 12 13:57:32 2008 From: superdadusa at gmail.com (John Choi) Date: Tue, 12 Aug 2008 13:57:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. Message-ID: Hi all, Just let you all know I just start to learn Java. I have download the serial comm package and the source code from open source communities.. I was able to verify with the given message string via serial monitor. when the given message string sends to the serial port then the character return added to the end of string by default if I use "Hello World" however if I changed to something else other than "Hello, World" there is no character return add to the end of string. I thing the library download from rxtx.org has implemented for the special strings. I can do like "login\n" in the string message to make character return but I don't want to add this individual custom character for each command return in every static message string I send, Can any who have done this might help me? Basically, something like this,, Write and add function to the program write a command, Reads the respond from a serial device.. Function handles multiple messages, Write: "com open" Read: Welcome to my world" expected Write: "admin" Read: Password?, expected Write: "admin" Read: you are successfully login terminal, expected. And I need to add a separate function handler handles a character return add to the each command above. If anyone can help this I can do the reset? Thank you in advance, John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0011.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SerialIO.java Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0011.pl From Steffen.DETTMER at ingenico.com Wed Aug 13 02:16:38 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 13 Aug 2008 10:16:38 +0200 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: References: Message-ID: <20080813081638.GA25412@elberon.bln.de.ingenico.com> * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > I can do like "login\n" in the string message to make character > return but I don't want to add this individual custom character > for each command return in every static message string I send, and why not?! > Can any who have done this might help me? what's about with writing a small wrapper function adding the carriage return? However, this would be slow, because either you call write two times (very bad) or the string needs to be copied, \n appended and written (since you are using Java Performance probably isn't so critical). Personally I would write `"login\n"' and `username + "\n"' etc., because since it is part of the command it should be part of the command definition string. > Basically, something like this,, Write and add function to the program write > a command, Reads the respond from a serial device.. correctly reading a `line' is more difficult. If you cannot make assumptions about timeouts and/or you need to have low delay, you need to read byte wise. If you need to save CPU resources you might need to add some buffering layer that you can read byte-wise but that is reading blockwise with some small timeout (lets say for serial lines something around byte transmission time times three or so). > /* > * To change this template, choose Tools | Templates > * and open the template in the editor. > */ :) > package joliba; > > /** > * > * @author root > */ :) > // derived from SUN's examples in the javax.comm package > import java.io.*; > import java.util.*; > //import javax.comm.*; // for SUN's serial/parallel port libraries > import gnu.io.*; // for rxtxSerial library > > public class SerialIO implements Runnable, SerialPortEventListener { > static CommPortIdentifier portId; > static CommPortIdentifier saveportId; > static Enumeration portList; > InputStream inputStream; > SerialPort serialPort; > Thread readThread; You need a thread for your synchronous RPC-style protocol? > static String messageString = "Hello, world!"; > static OutputStream outputStream; > static boolean outputBufferEmptyFlag = false; > > public static void main(String[] args) { > boolean portFound = false; > String defaultPort; > > // determine the name of the serial port on several operating systems > String osname = System.getProperty("os.name","").toLowerCase(); > if ( osname.startsWith("windows") ) { > // windows > defaultPort = "COM1"; > } else if (osname.startsWith("linux")) { > // linux > defaultPort = "/dev/ttyS0"; > } else if ( osname.startsWith("mac") ) { > // mac > defaultPort = "????"; > } else { > System.out.println("Sorry, your operating system is not supported"); > return; > } Is such a construction recommended? Isn't there some abstraction (like COM1 working on any platform)? [...] > try { > // activate the OUTPUT_BUFFER_EMPTY notifier > serialPort.notifyOnOutputEmpty(true); > } catch (Exception e) { > System.out.println("Error setting event notification"); > System.out.println(e.toString()); > System.exit(-1); > } I doubt that -1 is defined, probably some 127 or so would be the result, maybe better simply `throw e'? > public void writetoport() { > System.out.println("Writing \""+messageString+"\" to "+serialPort.getName()); > try { > // write string to serial port > outputStream.write(messageString.getBytes()); > } catch (IOException e) {} > } maybe something like /** * Writes the given output string and an additional carriage * return to the current outputStream. */ public void writeStringToPort( /** The output string (without CR). */ String output ) throws IOException { String outputLine = output + "\n"; outputStream.write(outputLine.getBytes()); } ? > > public SerialIO() { > // initalize serial port > try { > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > } catch (PortInUseException e) {} if the port is in use, you continue? Wonder that this works in Java, I would assume serialPort beeing uninitialized which AFAIK is an error in Java. > try { > inputStream = serialPort.getInputStream(); > } catch (IOException e) {} > > try { > serialPort.addEventListener(this); > } catch (TooManyListenersException e) {} > > // activate the DATA_AVAILABLE notifier > serialPort.notifyOnDataAvailable(true); > > try { > // set port parameters > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > } catch (UnsupportedCommOperationException e) {} > > // start the read thread > readThread = new Thread(this); > readThread.start(); > > } I think in all those exception cases you can abort, because it is unlikely that ignoring those errors allow a successful continuation, so in this case maybe it would be better to add a throw clause to the method. > public void run() { > // first thing in the thread, we initialize the write operation > initwritetoport(); > try { > while (true) { > // write string to port, the serialEvent will read it > writetoport(); > Thread.sleep(1000); > } > } catch (InterruptedException e) {} > } Does this make sense? Your `SimpleReadApp' writes one and the same string each second? > public void serialEvent(SerialPortEvent event) { > switch (event.getEventType()) { > case SerialPortEvent.BI: > case SerialPortEvent.OE: > case SerialPortEvent.FE: > case SerialPortEvent.PE: > case SerialPortEvent.CD: > case SerialPortEvent.CTS: > case SerialPortEvent.DSR: > case SerialPortEvent.RI: > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > break; > case SerialPortEvent.DATA_AVAILABLE: > // we get here if data has been received > byte[] readBuffer = new byte[20]; > try { > // read data > while (inputStream.available() > 0) { > int numBytes = inputStream.read(readBuffer); > } > // print data > String result = new String(readBuffer); > System.out.println("Read: "+result); > } catch (IOException e) {} I doubt that this is correct. I would assume you will get a 20 bytes result always, if more bytes would be available they would be printed in a second line but if less bytes are read I'd assume that the buffer/result contains zero bytes from implicite readBuffer contents initialisation (zero is no string terminator in Java AFAIK). > break; > } > } > } oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From florianmanschwetus at gmx.de Wed Aug 13 06:09:31 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 13 Aug 2008 14:09:31 +0200 Subject: [Rxtx] someone has seen such errors? Message-ID: <48A2CEFB.90007@gmx.de> I mean my communication mostly works, but it is far from perfect could this be the reason? Florian Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/949b9947/attachment-0011.bin From superdadusa at gmail.com Wed Aug 13 08:40:32 2008 From: superdadusa at gmail.com (John Choi) Date: Wed, 13 Aug 2008 08:40:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: <20080813081638.GA25412@elberon.bln.de.ingenico.com> References: <20080813081638.GA25412@elberon.bln.de.ingenico.com> Message-ID: Thank you so much Steffen and I will try that suggestion. John On 8/13/08, Steffen DETTMER wrote: > > * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > > I can do like "login\n" in the string message to make character > > return but I don't want to add this individual custom character > > for each command return in every static message string I send, > > and why not?! > > > Can any who have done this might help me? > > what's about with writing a small wrapper function adding the > carriage return? > However, this would be slow, because either you call write two > times (very bad) or the string needs to be copied, \n appended > and written (since you are using Java Performance probably isn't > so critical). > > Personally I would write `"login\n"' and `username + "\n"' etc., > because since it is part of the command it should be part of the > command definition string. > > > Basically, something like this,, Write and add function to the program > write > > a command, Reads the respond from a serial device.. > > correctly reading a `line' is more difficult. If you cannot make > assumptions about timeouts and/or you need to have low delay, you > need to read byte wise. If you need to save CPU resources you > might need to add some buffering layer that you can read > byte-wise but that is reading blockwise with some small timeout > (lets say for serial lines something around byte transmission > time times three or so). > > > /* > > * To change this template, choose Tools | Templates > > * and open the template in the editor. > > */ > > :) > > > package joliba; > > > > /** > > * > > * @author root > > */ > > :) > > > // derived from SUN's examples in the javax.comm package > > import java.io.*; > > import java.util.*; > > //import javax.comm.*; // for SUN's serial/parallel port libraries > > import gnu.io.*; // for rxtxSerial library > > > > public class SerialIO implements Runnable, SerialPortEventListener { > > static CommPortIdentifier portId; > > static CommPortIdentifier saveportId; > > static Enumeration portList; > > InputStream inputStream; > > SerialPort serialPort; > > Thread readThread; > > You need a thread for your synchronous RPC-style protocol? > > > static String messageString = "Hello, world!"; > > static OutputStream outputStream; > > static boolean outputBufferEmptyFlag = false; > > > > public static void main(String[] args) { > > boolean portFound = false; > > String defaultPort; > > > > // determine the name of the serial port on several operating > systems > > String osname = System.getProperty("os.name","").toLowerCase(); > > if ( osname.startsWith("windows") ) { > > // windows > > defaultPort = "COM1"; > > } else if (osname.startsWith("linux")) { > > // linux > > defaultPort = "/dev/ttyS0"; > > } else if ( osname.startsWith("mac") ) { > > // mac > > defaultPort = "????"; > > } else { > > System.out.println("Sorry, your operating system is not > supported"); > > return; > > } > > Is such a construction recommended? Isn't there some abstraction > (like COM1 working on any platform)? > > [...] > > try { > > // activate the OUTPUT_BUFFER_EMPTY notifier > > serialPort.notifyOnOutputEmpty(true); > > } catch (Exception e) { > > System.out.println("Error setting event notification"); > > System.out.println(e.toString()); > > System.exit(-1); > > } > > I doubt that -1 is defined, probably some 127 or so would be the > result, maybe better simply `throw e'? > > > public void writetoport() { > > System.out.println("Writing \""+messageString+"\" to > "+serialPort.getName()); > > try { > > // write string to serial port > > outputStream.write(messageString.getBytes()); > > } catch (IOException e) {} > > } > > maybe something like > > /** > * Writes the given output string and an additional carriage > * return to the current outputStream. > */ > public void > writeStringToPort( > /** The output string (without CR). */ > String output > ) throws IOException > { > String outputLine = output + "\n"; > outputStream.write(outputLine.getBytes()); > } > > ? > > > > > public SerialIO() { > > // initalize serial port > > try { > > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > > } catch (PortInUseException e) {} > > if the port is in use, you continue? Wonder that this works in > Java, I would assume serialPort beeing uninitialized which AFAIK > is an error in Java. > > > try { > > inputStream = serialPort.getInputStream(); > > } catch (IOException e) {} > > > > try { > > serialPort.addEventListener(this); > > } catch (TooManyListenersException e) {} > > > > // activate the DATA_AVAILABLE notifier > > serialPort.notifyOnDataAvailable(true); > > > > try { > > // set port parameters > > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > } catch (UnsupportedCommOperationException e) {} > > > > // start the read thread > > readThread = new Thread(this); > > readThread.start(); > > > > } > > I think in all those exception cases you can abort, because it is > unlikely that ignoring those errors allow a successful > continuation, so in this case maybe it would be better to add a > throw clause to the method. > > > public void run() { > > // first thing in the thread, we initialize the write operation > > initwritetoport(); > > try { > > while (true) { > > // write string to port, the serialEvent will read it > > writetoport(); > > Thread.sleep(1000); > > } > > } catch (InterruptedException e) {} > > } > > Does this make sense? Your `SimpleReadApp' writes one and the > same string each second? > > > public void serialEvent(SerialPortEvent event) { > > switch (event.getEventType()) { > > case SerialPortEvent.BI: > > case SerialPortEvent.OE: > > case SerialPortEvent.FE: > > case SerialPortEvent.PE: > > case SerialPortEvent.CD: > > case SerialPortEvent.CTS: > > case SerialPortEvent.DSR: > > case SerialPortEvent.RI: > > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > > break; > > case SerialPortEvent.DATA_AVAILABLE: > > // we get here if data has been received > > byte[] readBuffer = new byte[20]; > > try { > > // read data > > while (inputStream.available() > 0) { > > int numBytes = inputStream.read(readBuffer); > > } > > // print data > > String result = new String(readBuffer); > > System.out.println("Read: "+result); > > } catch (IOException e) {} > > I doubt that this is correct. I would assume you will get a 20 > bytes result always, if more bytes would be available they would > be printed in a second line but if less bytes are read I'd assume > that the buffer/result contains zero bytes from implicite > readBuffer contents initialisation (zero is no string terminator > in Java AFAIK). > > > break; > > } > > } > > } > > oki, > > Steffen > > About Ingenico Throughout the world businesses rely on Ingenico for secure > and expedient electronic transaction acceptance. Ingenico products leverage > proven technology, established standards and unparalleled ergonomics to > provide optimal reliability, versatility and usability. This comprehensive > range of products is complemented by a global array of services and > partnerships, enabling businesses in a number of vertical sectors to accept > transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged > information. If you are not the addressee or authorized to receive this for > the addressee, you must not use, copy, disclose or take any action based on > this message or any information herein. If you have received this message in > error, please advise the sender immediately by reply e-mail and delete this > message. Thank you for your cooperation. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/73c4135c/attachment-0010.html From ajmas at sympatico.ca Sat Aug 16 07:15:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 09:15:41 -0400 Subject: [Rxtx] someone has seen such errors? In-Reply-To: <48A2CEFB.90007@gmx.de> References: <48A2CEFB.90007@gmx.de> Message-ID: <43B5E8DA-1D93-4D90-809B-AAF35FF724C5@sympatico.ca> On 13-Aug-08, at 08:09 , Florian Manschwetus wrote: > I mean my communication mostly works, but it is far from perfect > could this be the reason? > > Florian > > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control Judging by the error messages this looks related to the driver you are using. Do a search for the following string with you favourite search engine, it should turn up a few hits: ftdi_set_termios FAILED to set databits/stopbits/parity Andre From ajmas at sympatico.ca Sat Aug 16 19:12:04 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 21:12:04 -0400 Subject: [Rxtx] Using SerialPortEvent? Message-ID: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Hi, Could someone tell me how I should be using the SerialPortEvent? Am I meant to be waiting for data and then simply reading from the inputstream? If this is the case why no just block on an inputstream read? Andr? From tjarvi at qbang.org Sat Aug 16 19:41:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 16 Aug 2008 19:41:13 -0600 (MDT) Subject: [Rxtx] Using SerialPortEvent? In-Reply-To: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> References: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Message-ID: On Sat, 16 Aug 2008, Andre-John Mas wrote: > Hi, > > Could someone tell me how I should be using the SerialPortEvent? Am I > meant to be waiting for data and then simply reading from the > inputstream? If this is the case why no just block on an inputstream > read? > Polling for data is fine also. It really depends upon what you are trying to do. For instance, if you require x bytes before reading, you can start polling after data is available. If you read on the same thread as your GUI and are waiting for data in a read, the results may be less than desirable. Java programming is 'usually' event driven rather than polling based. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sat Aug 16 20:10:39 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 22:10:39 -0400 Subject: [Rxtx] Using SerialPortEvent? In-Reply-To: References: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Message-ID: <3E495D4C-BB28-4845-A6AB-984C9A826BDF@sympatico.ca> On 16-Aug-08, at 21:41 , Trent Jarvi wrote: > On Sat, 16 Aug 2008, Andre-John Mas wrote: > >> Hi, >> >> Could someone tell me how I should be using the SerialPortEvent? Am I >> meant to be waiting for data and then simply reading from the >> inputstream? If this is the case why no just block on an inputstream >> read? >> > > Polling for data is fine also. It really depends upon what you are > trying to do. For instance, if you require x bytes before reading, > you can start polling after data is available. If you read on the > same thread as your GUI and are waiting for data in a read, the > results may be less than desirable. > > Java programming is 'usually' event driven rather than polling based. Sounds good. I thought I would use this opportunity to provide a event based version of the TwoWaySerialComm example. Could you just validate it before I add it to the Wiki: package ajmas74.experimental; import gnu.io.CommPort; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; import gnu.io.SerialPortEvent; import gnu.io.SerialPortEventListener; import java.io.IOException; import java.io.InputStream; import java.io.OutputStream; /** * This version of the TwoWaySerialComm example makes use of the * SerialPortEventListener to avoid polling. * * @author ajmas * */ public class TwoWaySerialComm { public TwoWaySerialComm() { super(); } void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { CommPort commPort = portIdentifier.open(this.getClass().getName(),2000); if ( commPort instanceof SerialPort ) { SerialPort serialPort = (SerialPort) commPort; serialPort .setSerialPortParams (57600 ,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); (new Thread(new SerialWriter(out))).start(); serialPort.addEventListener(new SerialReader(in)); } else { System.out.println("Error: Only serial ports are handled by this example."); } } } /** * Handles the input coming from the serial port. A new line character * is treated as the end of a block in this example. */ public static class SerialReader implements SerialPortEventListener { private InputStream in; private byte[] buffer = new byte[1024]; public SerialReader ( InputStream in ) { this.in = in; } public void serialEvent(SerialPortEvent arg0) { int data; try { int len = 0; while ( ( data = in.read()) > -1 ) { if ( data != '\n' ) { break; } buffer[len++] = (byte) data; } System.out.print(new String(buffer,0,len)); } catch ( IOException e ) { e.printStackTrace(); System.exit(-1); } } } /** */ public static class SerialWriter implements Runnable { OutputStream out; public SerialWriter ( OutputStream out ) { this.out = out; } public void run () { try { int c = 0; while ( ( c = System.in.read()) > -1 ) { this.out.write(c); } } catch ( IOException e ) { e.printStackTrace(); System.exit(-1); } } } public static void main ( String[] args ) { try { (new TwoWaySerialComm()).connect("COM3"); } catch ( Exception e ) { e.printStackTrace(); } } } From lfarkas at lfarkas.org Tue Aug 19 07:32:59 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Tue, 19 Aug 2008 15:32:59 +0200 Subject: [Rxtx] JNI or CNI Message-ID: <48AACB8B.9060606@lfarkas.org> hi, what is the current recommended way to rxtx on linux JNI or it's better to use CNI? is the CNI version fully functional and the same level as the JNI? i currently try to make a rhel/centos/fedora rpm for rxtx but has many problems with the standard dir structure. yours. -- Levente "Si vis pacem para bellum!" From lfarkas at lfarkas.org Tue Aug 19 08:47:34 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Tue, 19 Aug 2008 16:47:34 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel Message-ID: <48AADD06.7040809@lfarkas.org> hi, newer or not so newer linux kernel do not contain the UTS_RELEASE so the current rxtx is not compile on the latest kernels. even if it's commented out in the cvs configure there are other places. i attcahed a patch which fix it (or at least doesn't cause error at non-debug build). ps. is there any plan to the new 2.1-8 release in the near future? there are many changes (at least the license change in all file and in this case create a diff is very difficult)? the latest release more then 2 years old:-( -- Levente "Si vis pacem para bellum!" -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-2.1-uts.patch Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080819/ab5d38ac/attachment-0004.pl From ajmas at sympatico.ca Tue Aug 19 16:21:53 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 19 Aug 2008 18:21:53 -0400 Subject: [Rxtx] Event based example Message-ID: <24735BFB-B088-4B84-8173-FE98DF63B12F@sympatico.ca> Hi, I have just posted an example of using SerialPortEventListener in the Wiki: http://rxtx.qbang.org/wiki/index.php/Event_Based_Two_Way_Communication If you see any issues please could you let me know, or makes the changes. Andre From Martin.Oberhuber at windriver.com Fri Aug 22 04:02:24 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 22 Aug 2008 12:02:24 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <48AADD06.7040809@lfarkas.org> References: <48AADD06.7040809@lfarkas.org> Message-ID: <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> Farkas, there are indeed efforts to get a new RXTX release out the door. Your experience as a package maintainer would likely be helpful during these efforts, since I'd think it makes sense to keep the patches minimal that you must make to have the source compile in your environment. What are the things that you find problematic, apart from the UTS thing that you have mentioned before? What is the timing that you have in mind for your package? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Farkas Levente > Sent: Tuesday, August 19, 2008 4:48 PM > To: rxtx at qbang.org > Subject: [Rxtx] UTS_RELEASE not defined in newer kernel > > hi, > newer or not so newer linux kernel do not contain the > UTS_RELEASE so the > current rxtx is not compile on the latest kernels. even if it's > commented out in the cvs configure there are other places. > i attcahed a patch which fix it (or at least doesn't cause error at > non-debug build). > > ps. is there any plan to the new 2.1-8 release in the near > future? there > are many changes (at least the license change in all file and in this > case create a diff is very difficult)? the latest release more then 2 > years old:-( > > -- > Levente "Si vis pacem para bellum!" > From lfarkas at lfarkas.org Fri Aug 22 04:36:26 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Fri, 22 Aug 2008 12:36:26 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> References: <48AADD06.7040809@lfarkas.org> <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> Message-ID: <48AE96AA.6090505@lfarkas.org> hi, the packages already build for fedora-9 and centos-5 and here: http://www.lfarkas.org/linux/packages/ what i've to patch, the UTS, the configure script, but it's already fixed in the cvs (in another way) and the loadlibrary. the reasons for last one can be found here: https://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_files_that_use_JNI after we test it i'd like to add these packages to fedora and epel main repository (that's why it's be useful a new release after 2 years:-) imho versions are cheap and why not just release 2.1-8? the real code changes are minimal and if something critical bug found still can release 2.1-9:-) ps. and would be better to use simple number for version like 2.1-7 rather then 2.1-7v2. Oberhuber, Martin wrote: > Farkas, > > there are indeed efforts to get a new RXTX release out the > door. Your experience as a package maintainer would likely > be helpful during these efforts, since I'd think it makes > sense to keep the patches minimal that you must make to > have the source compile in your environment. > > What are the things that you find problematic, apart from > the UTS thing that you have mentioned before? > > What is the timing that you have in mind for your package? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >> On Behalf Of Farkas Levente >> Sent: Tuesday, August 19, 2008 4:48 PM >> To: rxtx at qbang.org >> Subject: [Rxtx] UTS_RELEASE not defined in newer kernel >> >> hi, >> newer or not so newer linux kernel do not contain the >> UTS_RELEASE so the >> current rxtx is not compile on the latest kernels. even if it's >> commented out in the cvs configure there are other places. >> i attcahed a patch which fix it (or at least doesn't cause error at >> non-debug build). >> >> ps. is there any plan to the new 2.1-8 release in the near >> future? there >> are many changes (at least the license change in all file and in this >> case create a diff is very difficult)? the latest release more then 2 >> years old:-( >> >> -- >> Levente "Si vis pacem para bellum!" >> -- Levente "Si vis pacem para bellum!" From tjarvi at qbang.org Fri Aug 22 18:50:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Aug 2008 18:50:32 -0600 (MDT) Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <48AE96AA.6090505@lfarkas.org> References: <48AADD06.7040809@lfarkas.org> <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> <48AE96AA.6090505@lfarkas.org> Message-ID: Hi Farkas, The v2 was simply the second build - no code changes. We are comming out with a new release shortly. I would encourage working with distros as you are. The building of rxtx turns out to be a bottle neck in quick releases. We do want stable releases that work for a year or more but I would have no problems with quicker cycles on developing work. I would have no problem working with someone that did builds that receive less testing more often but they do have to come out for multiple platforms from this end. Thanks for the links. On Fri, 22 Aug 2008, Farkas Levente wrote: > hi, > the packages already build for fedora-9 and centos-5 and here: > http://www.lfarkas.org/linux/packages/ > what i've to patch, the UTS, the configure script, but it's already > fixed in the cvs (in another way) and the loadlibrary. the reasons for > last one can be found here: > https://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_files_that_use_JNI > after we test it i'd like to add these packages to fedora and epel main > repository (that's why it's be useful a new release after 2 years:-) > imho versions are cheap and why not just release 2.1-8? the real code > changes are minimal and if something critical bug found still can > release 2.1-9:-) > > ps. and would be better to use simple number for version like 2.1-7 > rather then 2.1-7v2. > > Oberhuber, Martin wrote: >> Farkas, >> >> there are indeed efforts to get a new RXTX release out the >> door. Your experience as a package maintainer would likely >> be helpful during these efforts, since I'd think it makes >> sense to keep the patches minimal that you must make to >> have the source compile in your environment. >> >> What are the things that you find problematic, apart from >> the UTS thing that you have mentioned before? >> >> What is the timing that you have in mind for your package? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >>> On Behalf Of Farkas Levente >>> Sent: Tuesday, August 19, 2008 4:48 PM >>> To: rxtx at qbang.org >>> Subject: [Rxtx] UTS_RELEASE not defined in newer kernel >>> >>> hi, >>> newer or not so newer linux kernel do not contain the >>> UTS_RELEASE so the >>> current rxtx is not compile on the latest kernels. even if it's >>> commented out in the cvs configure there are other places. >>> i attcahed a patch which fix it (or at least doesn't cause error at >>> non-debug build). >>> >>> ps. is there any plan to the new 2.1-8 release in the near >>> future? there >>> are many changes (at least the license change in all file and in this >>> case create a diff is very difficult)? the latest release more then 2 >>> years old:-( >>> >>> -- >>> Levente "Si vis pacem para bellum!" >>> > > > From rick_knight at rlknight.com Mon Aug 4 13:25:10 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Mon, 04 Aug 2008 12:25:10 -0700 Subject: [Rxtx] Sun's Comm API? Message-ID: <48975796.4010600@rlknight.com> I have an application that requires the javax compatible version of RXTX and Sun's comm api. I've been able to download and extract the version of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api anywhere. Can someone tell me where I can find it? Or maybe send me a copy? Also, when I try to build RXTX, configure and make complete successfully but make install failes with this error libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 I've never come accross this error before. How can I get past it? Thanks, Rick From bboyes at systronix.com Mon Aug 4 19:10:01 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:10:01 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48975796.4010600@rlknight.com> References: <48975796.4010600@rlknight.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/cb9c6167/attachment-0020.html From bboyes at systronix.com Mon Aug 4 19:12:37 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:12:37 -0600 Subject: [Rxtx] Towards an RXTX release - CSR BT/USB chipset In-Reply-To: <488FB7E7.8000802@gmail.com> References: <460801A4097E3D4CA04CC64EE648584806C56CF0@ism-mail03.corp.ad.wrs.com> <13557-75390@sneakemail.com> <20980-23424@sneakemail.com> <488FB7E7.8000802@gmail.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/52236088/attachment-0020.html From tjarvi at qbang.org Mon Aug 4 19:42:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 19:42:21 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: On Mon, 4 Aug 2008, Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: > I have an application that requires the javax compatible > version of RXTX > and Sun's comm api. I've been able to download and extract > the version > of RXTX that I need (2.0-7pre2) but I can't find Sun's camm > api > anywhere. Can someone tell me where I can find it? Or maybe > send me a > > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm port > support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have just > a ZIP with only the .class JAR file - no source or docs), has a readme > with these comments: > > This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release.? The 2.0.3 release itself is > no longer distributed.? comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project.? The RxTx project (http://www.rxtx.org ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org) was opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support.? Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins.? Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > ? > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > I hope that is helpful! > It would be nice to work with Sun to resolve those longstanding issues. But it may not be practical unless the process goes as fast and painless as the grandfathering of commapi did. Another option may be the old kaffe extensions that moved to gnu classpathx. These don't have the native libraries but should provide the 2.0 interface and the javax.comm.properties mechansim for SPI. http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Mon Aug 4 20:23:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Mon, 04 Aug 2008 20:23:57 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4897B9BD.5070809@ergotech.com> Has there been any work/would it be possible, to layer a javacomm look-alike on top of the GNU code? The goal is not to move the javax code forward, but to emulate the "legacy" javax packages for people who still need this. Jim Trent Jarvi wrote: > On Mon, 4 Aug 2008, Bruce Boyes wrote: > >> At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible >> version of RXTX >> and Sun's comm api. I've been able to download and extract >> the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm >> api >> anywhere. Can someone tell me where I can find it? Or maybe >> send me a >> >> >> javaxcomm has had a sort of on-again off-again history. The windoze >> version has been languishing for years (literally) but there are newer >> versions for other OS's. >> >> We try to keep links on one of our help pages current: >> http://www.practicalembeddedjava.com/tools/javatools_list.html >> which gets you to here: >> http://java.sun.com/products/javacomm/ >> where it says in fact they no longer even support Windows and Mac: >> "Implementations of the API are currently available for Solaris SPARC, >> Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so >> someone could support it. But I guess that's part of the reason RXTX >> exists! >> >> So one of Sun's own products, SunSPOT, has to use RXTX to get comm port >> support. >> >> The version we use is 2.0 from 11/15/1998. I have posted it on our >> website, which is within the terms of the license agreement contained >> therein (as I understand it). >> >> The last version of javaxcomm for Windows, 2.0.3, (for which I have just >> a ZIP with only the .class JAR file - no source or docs), has a readme >> with these comments: >> >> This distribution contains the comm.jar file original part >> of the COMMAPI 2.0.3 release. The 2.0.3 release itself is >> no longer distributed. comm.jar, which contains the comm >> API java class files (eg. Sun's binary implementation of the >> interface classes), is being made available, unsupported, >> with no obligation to fix bugs, at the request of the RXTX >> project. The RxTx project (http://www.rxtx.org ), uses the >> comm.jar class files, but provides their own native library >> components to provide support for other platforms. >> >> The 2.0.3 comm.jar is being provided in this way because >> as of COMMAPI 3.x, the java binary implementation forked and >> became incompatible with the RxTx project's native code. >> Due to the lack of a clear business case, and to resource >> constraints, no additional resources are being >> provided to provide an alternative engineering solution >> at the time of writing. >> >> RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: >> >> Ultimately the COMMAPI would be better served if a Java >> Community Process JSR (http://www.jcp.org) was opened and >> the COMMAPI was rearchitected to provide a more pluggable >> framework to improve cross-platform support. Such an >> architecture would embody a better defined and better >> documented SPI interface, including a way for comm. ports >> to be revealed to the client application through the API >> via platform-aware plugins. Similarly, native code used >> to access comm port in general could be handled more >> flexibly using a plugin model, whereby on any platform, >> multiple native modules could be in use simultaneously. >> >> Since there are now various ways serial ports can be implemented >> and accessed, modular comm. port JNI native libraries would be >> of benefit insofar as removing the burden of over-generalization >> from any single native component, or inversely, by relieving the >> implicit constraint that comm. drivers be accessed only via a >> monolithic mechanism, such as the UNIX vnode interface. >> >> paul.klissner at sun.com >> 6/10/06 >> >> I hope that is helpful! >> > > It would be nice to work with Sun to resolve those longstanding issues. > But it may not be practical unless the process goes as fast and painless > as the grandfathering of commapi did. > > Another option may be the old kaffe extensions that moved to gnu > classpathx. These don't have the native libraries but should provide > the 2.0 interface and the javax.comm.properties mechansim for SPI. > > http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Mon Aug 4 21:09:15 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 21:09:15 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? Message-ID: Hi Jim, I will not step into the javax.comm namespace without Sun's explicite permission. I fully understand the pain point you are trying to address. In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm Linux) - which remains an integral part of rxtx. At the time it was a win for Sun and rxtx. The Sun commapi license is/was fairly clear that rxtx should not step into that namespace. It made sense as Sun was active in that space and rxtx may go into another namespace - it was an experiment in working with Sun. This may sound silly looking at something that happened almost 10 years ago. In a community of respect which Sun helped create, there is no question about what to do. I hope eventually Sun will step up and do a right thing too. I agree that this is hurting the API more than helping it. There are also questions about how to replace the API in the long term which includes HID support which isn't going well so far. Others that can't even look at Sun's javax.comm today and can look at Kaffe's contribution to classpathx can easily work around such restrictions. On Mon, 4 Aug 2008, Jim Redman wrote: > Has there been any work/would it be possible, to layer a javacomm > look-alike on top of the GNU code? > > The goal is not to move the javax code forward, but to emulate the > "legacy" javax packages for people who still need this. > > Jim > > Trent Jarvi wrote: >> >> It would be nice to work with Sun to resolve those longstanding issues. >> But it may not be practical unless the process goes as fast and painless >> as the grandfathering of commapi did. >> >> Another option may be the old kaffe extensions that moved to gnu >> classpathx. These don't have the native libraries but should provide >> the 2.0 interface and the javax.comm.properties mechansim for SPI. >> >> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From florianmanschwetus at gmx.de Tue Aug 5 05:04:46 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 13:04:46 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: References: <48971C1F.9020806@gmx.de> Message-ID: <489833CE.1040801@gmx.de> Just look at sendCommand in this method I have to place a Thread.sleep(20) after each byte send to get working. Even the event based receive doesn't work fine but this could be may stupidness. The specifikation document (it is on the last pages of the manual) for the beamer could be found on: http://www.optoma.co.uk/support.aspx Florian Manschwetus Trent Jarvi schrieb: > > Hi Florian > > Sorry for the top post in advance. I worry you may not see my answer > under all your code :) > > I have not received this email before. This is 500k of code which I > don't have time to read. I can spend about 5 min on each hobby email > and still get to work in the morning. I have a couple suggestions for > how to get an answer. > > First, cut out your comments and extra code so you can demonstrate the > question (I might even glance and see what is wrong then). Don't go for > a working final product. Isolate the problem using a simple program and > then ask with that as an example. If I did what you just did, I'd have > to post 3/4 of a million lines of code :) > > Second, join the rxtx mail-list and ask there. This will give you 100x > more eyes. I'll also read and try to follow. > > -- > taj > > > > On Mon, 4 Aug 2008, Florian Manschwetus wrote: > >> It could be that my university account is blocked by filters so >> resending from here. >> >> >> Topic is to control Optoma HD80 beamer using rs232 serial chat. >> This code is able to detect power state and switch the beamer on / off. >> connected is the beamer using a digitus usb 2.0 serial adapter with an >> FT232 USB-Serial adapter the systems architecture is amd64. >> >> Please take a look in the sendCommand routine i have to place theire >> those Thread.sleep to get it working. >> Now the question is this correct or is there a better way to get this >> working correctly? >> >> In the javadoc coming with the install i found this: >> setBaudBase >> >> public boolean setBaudBase(int BaudBase) >> throws UnsupportedCommOperationException, >> java.io.IOException >> >> Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 >> before using. >> >> could this explain the error? >> I attached my java source and the protocol description for the beamer >> (available on vendor website). >> >> thx, >> Florian Manschwetus >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: TestRS232.java Type: text/x-java Size: 9143 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0040.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0041.bin From michael.erskine at ketech.com Tue Aug 5 05:53:49 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Tue, 5 Aug 2008 12:53:49 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489833CE.1040801@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> > Just look at sendCommand in this method I have to place a > Thread.sleep(20) after each byte send to get working. Even the event > based receive doesn't work fine but this could be may stupidness. Hi Florian, Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. Regards, Michael Erskine. From florianmanschwetus at gmx.de Tue Aug 5 07:28:15 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:28:15 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> Message-ID: <4898556F.8000208@gmx.de> Michael Erskine schrieb: >> Just look at sendCommand in this method I have to place a >> Thread.sleep(20) after each byte send to get working. Even the event >> based receive doesn't work fine but this could be may stupidness. > > Hi Florian, > > Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. > > Regards, > Michael Erskine. > Ok, sounds fine for the receiving problem. But why i have to wait after each byte when sending a command squence? (the for loop in send command) Florian > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/284f350c/attachment-0019.bin From florianmanschwetus at gmx.de Tue Aug 5 07:44:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:44:14 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <4898592E.2020908@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >>> Just look at sendCommand in this method I have to place a >>> Thread.sleep(20) after each byte send to get working. Even the event >>> based receive doesn't work fine but this could be may stupidness. >> >> Hi Florian, >> >> Yes, naturally you'll have to wait for a response from the other end. >> Why not wait for notification from the event thread perhaps using a >> BlockingDeque rather than your LinkedList. Generally I >> try to decouple all input and output streams: in your case your >> application is operating synchronously like the "expect" program >> (http://expect.nist.gov/) so waits (or timeouts) will need to be >> factored in. >> >> Regards, >> Michael Erskine. >> > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) > > Florian Furthermore there is this basic baud with this confusing javadoc entry: public boolean setBaudBase(int BaudBase) throws UnsupportedCommOperationException, java.io.IOException Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 before using. maybe this could explain something Florian >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/006c7425/attachment-0019.bin From jredman at ergotech.com Tue Aug 5 09:13:36 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 05 Aug 2008 09:13:36 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: Message-ID: <48986E20.3060104@ergotech.com> Trent, So two issues: 1) Technically I'm still not sure how easy/practical a layer would be. The problems are always classes like listeners, and wrapping returns of gnu.io classes. I really see it as a "delegate" type of concept. Any thoughts or ideas of the practicality of this approach? The idea is not to modify RXTX. 2) Javax. The javax namespace does seem to be in widespread use outside of Sun (the same is true for the java namespace). The classpath extensions, or some other location, should be interested in a JavaComm implementation even if it does have dependencies on RXTX. Would you have any philosophical objection to an approach like that? Of course, I suspect it might be better if someone with that authority at Sun would admit that the javax namespace is already in the wild and that there is no problem with it being used within RXTX. Jim Trent Jarvi wrote: > Hi Jim, > > I will not step into the javax.comm namespace without Sun's explicite > permission. I fully understand the pain point you are trying to address. > > In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm > Linux) - which remains an integral part of rxtx. At the time it was a win for > Sun and rxtx. > > The Sun commapi license is/was fairly clear that rxtx should not step into that > namespace. It made sense as Sun was active in that space and rxtx may go into > another namespace - it was an experiment in working with Sun. > > This may sound silly looking at something that happened almost 10 years ago. > In a community of respect which Sun helped create, there is no question about > what to do. I hope eventually Sun will step up and do a right thing too. > > I agree that this is hurting the API more than helping it. There are also > questions about how to replace the API in the long term which includes HID > support which isn't going well so far. > > Others that can't even look at Sun's javax.comm today and can look at Kaffe's > contribution to classpathx can easily work around such restrictions. > > On Mon, 4 Aug 2008, Jim Redman wrote: > >> Has there been any work/would it be possible, to layer a javacomm >> look-alike on top of the GNU code? >> >> The goal is not to move the javax code forward, but to emulate the >> "legacy" javax packages for people who still need this. >> >> Jim >> >> Trent Jarvi wrote: >>> It would be nice to work with Sun to resolve those longstanding issues. >>> But it may not be practical unless the process goes as fast and painless >>> as the grandfathering of commapi did. >>> >>> Another option may be the old kaffe extensions that moved to gnu >>> classpathx. These don't have the native libraries but should provide >>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>> >>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From sandeep at genevasoftech.com Tue Aug 5 11:18:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Tue, 05 Aug 2008 22:48:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <48988B6C.5080409@genevasoftech.com> Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. *-- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/ad20f1cb/attachment-0019.html From Martin.Oberhuber at windriver.com Tue Aug 5 13:30:17 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Tue, 5 Aug 2008 21:30:17 +0200 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Sandeep, shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on Sol7 but I've successfully run it on Sol9 and Sol10. Or is your request really about a native 64bit variant? I'm afraid that then you're out of luck since I think that quite a bit of RXTX is not yet ready for 64 bit. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Sandeep Kumar K Sent: Tuesday, August 05, 2008 7:19 PM To: rxtx at qbang.org Subject: [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so for Solaris 9 Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. -- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/81b7f988/attachment-0019.html From tjarvi at qbang.org Tue Aug 5 22:38:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 22:38:34 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 5 Aug 2008, Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built > on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid that > then > you're out of luck since I think that quite a bit of RXTX is not yet > ready > for 64 bit. > While rxtx-2.1-7 probably has problems, The CVS code should be OK for 64 bit Solaris. If it isn't, let me know and I'll find which patch is missing. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Aug 5 23:13:00 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 23:13:00 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48986E20.3060104@ergotech.com> References: <48986E20.3060104@ergotech.com> Message-ID: On Tue, 5 Aug 2008, Jim Redman wrote: > Trent, > > So two issues: > > 1) Technically I'm still not sure how easy/practical a layer would be. The > problems are always classes like listeners, and wrapping returns of gnu.io > classes. I really see it as a "delegate" type of concept. Any thoughts or > ideas of the practicality of this approach? The idea is not to modify RXTX. I have not put too much thought into this. I assume you want what rxtx 2.0 provided to tie into javax.comm implementations. More classes could be added to rxtx 2.1-7 for SPI support. Maintaining rxtx-2.0 could also be handed to someone if they like. > > 2) Javax. The javax namespace does seem to be in widespread use outside of > Sun (the same is true for the java namespace). The classpath extensions, or > some other location, should be interested in a JavaComm implementation even > if it does have dependencies on RXTX. Would you have any philosophical > objection to an approach like that? > No problems. Classpathx would be a possible place to do it. I'd suggest thinking twice about what this involves in practical terms. You would be wanting to revive the 2.0 API while Sun is at 3.0 and grandfathering the JSR. This undermines the main reason (established api) for using the javax.comm namespace and does not leave such a project in a good position. The only win I see here is maintaining support for applications that can't migrate namespaces. Not that that isn't important. At some point it is going to be less work to just edit the bytecode :) Such a javax.comm effort would also be signing up new projects that decided to use the work up for concerns they probably will not understand or expect. That probably isn't a good path to facilitate for new projects at this time. We will put a good faith effort to work well with others but keep in mind the project has limited bandwidth for such efforts. > Of course, I suspect it might be better if someone with that authority at Sun > would admit that the javax namespace is already in the wild and that there is > no problem with it being used within RXTX. > > Jim > > Trent Jarvi wrote: >> Hi Jim, >> >> I will not step into the javax.comm namespace without Sun's explicite >> permission. I fully understand the pain point you are trying to address. >> >> In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java >> Comm Linux) - which remains an integral part of rxtx. At the time it was a >> win for Sun and rxtx. >> >> The Sun commapi license is/was fairly clear that rxtx should not step into >> that namespace. It made sense as Sun was active in that space and rxtx may >> go into another namespace - it was an experiment in working with Sun. >> >> This may sound silly looking at something that happened almost 10 years >> ago. In a community of respect which Sun helped create, there is no >> question about what to do. I hope eventually Sun will step up and do a >> right thing too. >> >> I agree that this is hurting the API more than helping it. There are also >> questions about how to replace the API in the long term which includes HID >> support which isn't going well so far. >> >> Others that can't even look at Sun's javax.comm today and can look at >> Kaffe's contribution to classpathx can easily work around such >> restrictions. >> >> On Mon, 4 Aug 2008, Jim Redman wrote: >> >>> Has there been any work/would it be possible, to layer a javacomm >>> look-alike on top of the GNU code? >>> >>> The goal is not to move the javax code forward, but to emulate the >>> "legacy" javax packages for people who still need this. >>> >>> Jim >>> >>> Trent Jarvi wrote: >>>> It would be nice to work with Sun to resolve those longstanding issues. >>>> But it may not be practical unless the process goes as fast and painless >>>> as the grandfathering of commapi did. >>>> >>>> Another option may be the old kaffe extensions that moved to gnu >>>> classpathx. These don't have the native libraries but should provide >>>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>>> >>>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From sandeep at genevasoftech.com Wed Aug 6 00:03:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Wed, 06 Aug 2008 11:33:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: <48993EB8.30107@genevasoftech.com> Thank you Mr. Martin for your suggestion. The native file which is given in rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am getting the following error . Any suggestions to solve this issue. I am using Solaris SPARC 64 bit machine. ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) thrown while loading gnu.io.RXTXCommDriver Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(Unknown Source) at java.lang.ClassLoader.loadLibrary(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) at com.ReadFromModem.main(ReadFromModem.java:84) * * *Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid > that then > you're out of luck since I think that quite a bit of RXTX is not yet ready > for 64 bit. > > Cheers, > -- > *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > ------------------------------------------------------------------------ > *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On > Behalf Of *Sandeep Kumar K > *Sent:* Tuesday, August 05, 2008 7:19 PM > *To:* rxtx at qbang.org > *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so > for Solaris 9 > > Hi, > > Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 > bit machine. The librxtxSerial.so given in website is for Solaris 8. > > *-- > > Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/1e920343/attachment-0019.html From tjarvi at qbang.org Wed Aug 6 00:21:42 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 00:21:42 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <48993EB8.30107@genevasoftech.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> <48993EB8.30107@genevasoftech.com> Message-ID: Hi Sandeep You may be out of luck unless you can compile the 2.1 src in CVS (requires gnu make and gcc). But you could try the ToyBox(R)(TM) which is a collection of WiLdLy untested cross compiled 2.1-7 binaries covering everything from the ibm z series to embeded arm/ppc. To give an idea how poorly these are tested, I don't even know if z series machines have a serial port. ftp://www.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Solaris They should at least match the binary types. Actually, I think if you use the rxtx jar from CVS with that file, it should 'work' as the fix for 64 bits was in java not the native code. You could just cd rxtx*/src; javac *.java then jar -cf RXTXcomm.jar `find -name \*.class` to create the hybrid which will complain about version information a bit. On Wed, 6 Aug 2008, Sandeep Kumar K wrote: > Thank you Mr. Martin for your suggestion. The native file which is given in > rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am > getting the following error . > Any suggestions to solve this issue. > I am using Solaris SPARC 64 bit machine. > > ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar > java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 > (Possible cause: architecture word > width mismatch) thrown while loading gnu.io.RXTXCommDriver > Exception in thread "main" java.lang.UnsatisfiedLinkError: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF > class: ELFCLASS64 (Possible cause: > architecture word width mismatch) > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(Unknown Source) > at java.lang.ClassLoader.loadLibrary(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > at com.ReadFromModem.main(ReadFromModem.java:84) > > * > * > > *Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > > > Oberhuber, Martin wrote: >> Sandeep, >> shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse >> variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on >> Sol7 but I've successfully run it on Sol9 and Sol10. >> Or is your request really about a native 64bit variant? I'm afraid that >> then >> you're out of luck since I think that quite a bit of RXTX is not yet ready >> for 64 bit. >> Cheers, >> -- >> *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> ------------------------------------------------------------------------ >> *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On >> Behalf Of *Sandeep Kumar K >> *Sent:* Tuesday, August 05, 2008 7:19 PM >> *To:* rxtx at qbang.org >> *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so >> for Solaris 9 >> >> Hi, >> >> Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 >> bit machine. The librxtxSerial.so given in website is for Solaris 8. >> >> *-- >> Thanks & Regards >> >> Sandeep Kumar K >> Sr. Software Engineer >> Geneva Software Technologies >> Whitefield, Bangalore >> Mob : 9880193454* >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> From michael.erskine at ketech.com Wed Aug 6 01:39:28 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 6 Aug 2008 08:39:28 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Florian Manschwetus wrote: > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) Hi Florian, I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. Regards, Michael Erskine. From florianmanschwetus at gmx.de Wed Aug 6 02:53:16 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 06 Aug 2008 10:53:16 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Message-ID: <4899667C.6010706@gmx.de> Michael Erskine schrieb: > Florian Manschwetus wrote: >> Ok, sounds fine for the receiving problem. >> But why i have to wait after each byte when sending a command squence? >> (the for loop in send command) > > Hi Florian, > I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. > > Regards, > Michael Erskine. > correct with a terminal on the other end it works, my idea was that this basic baud has some influence. Could some one explain what it is for? Florian > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/c2b4fa84/attachment-0019.bin From rick_knight at rlknight.com Wed Aug 6 13:01:07 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:01:07 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F4F3.3020707@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > I have an application (Readerware) that uses RXTX with Javax to access the serial port. This used to work fine under previous Linux' and Java, but something has changed, I assume with Java itself , that is causing the application to fail with a link error. The application is not able to find librxtxSerialParallel.so. RXTX supplies librxtxSerial.so and librxtxParallel.so, but not librxtxSerialParallel.so. Where can I get librxtxSerialParallel.so, or do I need it? Is something else causing the lib to not be found? Thanks, Rick Knight From rick_knight at rlknight.com Wed Aug 6 13:17:55 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:17:55 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F8E3.5060400@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Thanks for the reply. The developer of the app I'm trying to use (Readerware) has sent me a copy of the comm.api and I've copied the library (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar into the proper places. When I try to run the application, I get this error... Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: /usr/lib/libSolarisSerialParallel.so: /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not little-endian (Possible cause: endianness mismatch) Caught java.lang.UnsatisfiedLinkError: com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I while loading driver com.sun.comm.SolarisDriver Is there a way around this error? Thanks again, Rick Knight From jlar310 at gmail.com Wed Aug 6 13:37:42 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 14:37:42 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899F8E3.5060400@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > The developer of the app I'm trying to use (Readerware) has sent me a > copy of the comm.api and I've copied the library > (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar > into the proper places. When I try to run the application, I get this > error... > > Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: > /usr/lib/libSolarisSerialParallel.so: > /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not > little-endian (Possible cause: endianness mismatch) > Caught java.lang.UnsatisfiedLinkError: > com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I > > while loading driver com.sun.comm.SolarisDriver > > Is there a way around this error? What host OS are you running? From your original post it looks like 32 bit Linux. The libSolarisSerialParallel.so file is for Sun Solaris and will vary depending on the underlying hardware architecture as well. Sorry for the double post Rick, but I failed to send this to the list the first time... -- Jeff From rick_knight at rlknight.com Wed Aug 6 13:44:29 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:44:29 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: <4899FF1D.9030504@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > > >> The developer of the app I'm trying to use (Readerware) has sent me a >> copy of the comm.api and I've copied the library >> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >> into the proper places. When I try to run the application, I get this >> error... >> >> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >> /usr/lib/libSolarisSerialParallel.so: >> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >> little-endian (Possible cause: endianness mismatch) >> Caught java.lang.UnsatisfiedLinkError: >> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >> >> while loading driver com.sun.comm.SolarisDriver >> >> Is there a way around this error? >> > > What host OS are you running? From your original post it looks like 32 > bit Linux. > > The libSolarisSerialParallel.so file is for Sun Solaris and will vary > depending on the underlying hardware architecture as well. > > I'm running Kubuntu Linux (debian based). It's 32 bit. Rick Knight From jlar310 at gmail.com Wed Aug 6 15:33:23 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 16:33:23 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > I don't think Sun did binary libraries for Linux in the 2.0 version. Can someone with more historical experience than I confirm that? I recently tried to port a Comm API application from Solaris sparc to Linux x86 and likewise could not get my hands on the binary libraries. I eventually just re-wrote the code to use the gnu namespace packages and rxtx 2.1. What I don't understand is why your application vendor does not provide everything you need to run their software. FYI: I have librxtxParallel.so and librxtxSerial.so installed at JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is /usr/java/default which is actually a softlink to /usr/java/jre1.6.0_05. -- Jeff From defiantlew at yahoo.com.au Wed Aug 6 16:29:33 2008 From: defiantlew at yahoo.com.au (Lew L) Date: Thu, 7 Aug 2008 08:29:33 +1000 Subject: [Rxtx] Sun's Comm API Documentation References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> Message-ID: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> As a matter of interest is the Sun Comm API documentation available somewhere? I have tried the Sun site but it seems to have been removed. Unless I have missed the documentation for RXTX? I javadocced the RXTX source but information (to me) is minimal. Somewhere I got the impression that the Sun Comm API docs is, or was, compatible with RXTX, what is the best docs to use in conjuntion with RXTX and where may the be available? Cheers Lew From rick_knight at rlknight.com Wed Aug 6 17:18:33 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:18:33 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A3149.4050306@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff I'm not sure if I posted this here or not, but when I try to build RXTX from source I get this install error... make all-am make[1]: Entering directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' make[1]: Nothing to be done for `all-am'. make[1]: Leaving directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 Can you tell me how to get past this error and get RXTX built and installed? Thanks, Rick From bboyes at systronix.com Wed Aug 6 17:40:12 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Wed, 06 Aug 2008 17:40:12 -0600 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: At 16:29 08/06/2008, Lew L wrote: >As a matter of interest is the Sun Comm API documentation available >somewhere? I have tried the Sun site but it seems to have been removed. It's in the file we have posted, link in prev email (sorry, in a huge hurry right now). Javadocs definitely there. >Unless I have missed the documentation for RXTX? I javadocced the RXTX >source but information (to me) is minimal. >Somewhere I got the impression that the Sun Comm API docs is, or was, >compatible with RXTX, what is the best docs to use in conjuntion with RXTX >and where may the be available? Yeah, this is one of my concerns/beefs. There is little documentation for RXTX and it isn't just the same as javaxcomm. I would be willing to help out writing docs for RXTX! Yes really... esp if we can fix the Bluetooth issues. best regards Bruce >Cheers >Lew > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx ------- WWW.SYSTRONIX.COM ---------- Real embedded Java and much more +1-801-534-1017 Salt Lake City, USA From rick_knight at rlknight.com Wed Aug 6 17:54:08 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:54:08 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A39A0.2090309@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff, I would like for my vendor to switch to rxtx 2.1. It would make things much easier for me. I'm not sure why he's still using the javax compatible code. He's a small operation. Re-writing the code to use gnu namespace sounds like a major overhaul. Was it? Thanks, Rick From tjarvi at qbang.org Wed Aug 6 21:35:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:35:12 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: >> >>> Jeff wrote: >>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>>> >>>> >>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things > much easier for me. I'm not sure why he's still using the javax > compatible code. He's a small operation. Re-writing the code to use gnu > namespace sounds like a major overhaul. Was it? > Hi Jeff, The changes are fairly mechanical. Imports need to change and any explicite use of the namespace needs to change such as catching an exception. The following script was made for maintaining rxtx 2.0 but can apply to other needs. It is in the contrib dir with rxtx source. #!/bin/sh # Don't use! :) # # Sat, 03 May 2003 16:45:08 Modifications from J?rg Weule # Create a ed-cmd for the change of one pattern # case $1 in gnu) X=g/javax_comm/s+javax_comm+gnu_io+g ;; javax) X=g/gnu_io/s+gnu_io+javax_comm+g ;; *) echo;echo;echo From the top rxtx directory run;echo;echo -e \\t./ChangePackage.sh gnu;echo -e \\t\\tor;echo -e \\t./ChangePackage.sh javax;echo;echo; exit 0 ;; esac # # ed will be used to keep the owner and mode of the files unchanged. # We have run the ed-script for the characters '.' '/' as well. # "tr _ $D" do the change. # find . -type f -a -print | grep -v $0 | (while read F ; do ( echo $X; echo $X| tr _ /; echo $X| tr _ .; echo w; echo q ) | ed $F 2>&1 >/dev/null done ) # # Now we do little changes at the Makefiles. Hope that all we need. # find . -name Makefile\* -a -print | (while read F ; do cat < References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: On Thu, 7 Aug 2008, Lew L wrote: > As a matter of interest is the Sun Comm API documentation available > somewhere? I have tried the Sun site but it seems to have been removed. > > Unless I have missed the documentation for RXTX? I javadocced the RXTX > source but information (to me) is minimal. > Somewhere I got the impression that the Sun Comm API docs is, or was, > compatible with RXTX, what is the best docs to use in conjuntion with RXTX > and where may the be available? > Hi Lew, The documentation on Sun's website is accurate. The changes that are problematic in 3.0 are on the backside which rxtx used to plug into. http://java.sun.com/products/javacomm/reference/api/index.html CommPortIdentifier may have some minor differences (judging by the authors notes). -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Aug 6 21:46:08 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:46:08 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > If javax.comm.properties is properly installed and you are using a 2.0 version of Sun's commapi with rxtx 2.0, you should not see the library attempt to load libSolarisSerialParallel.so. Sun CommAPI 3.0 will not work with any version of rxtx as it is hard coded to use the shared library. See the INSTALL file with rxtx-2.0 source for more help with the properties file. -- Trent Jarvi tjarvi at qbang.org From jlar310 at gmail.com Thu Aug 7 06:32:06 2008 From: jlar310 at gmail.com (Jeff) Date: Thu, 7 Aug 2008 07:32:06 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > Jeff wrote: >> >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >> wrote: >> >>> >>> Jeff wrote: >>> >>>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>> wrote: >>>> >>>> >>>> >>>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things much > easier for me. I'm not sure why he's still using the javax compatible code. > He's a small operation. Re-writing the code to use gnu namespace sounds like > a major overhaul. Was it? I found it quite easy. In fact, in order to accommodate the transition, I actually separated all of the code that deals directly with the Comm API or RXTX into a helper class. The helper class was then coded to use reflection to determine which library was available and then instantiate the necessary objects. No direct imports of either library are used. The main application just needs to get it's hands on the IO streams and need not deal directly with the libraries. Other programs may not be so simple... But this doesn't really help you unless your vendor forks over the source code... -- Jeff From rick_knight at rlknight.com Thu Aug 7 09:47:12 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Thu, 07 Aug 2008 08:47:12 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: <489B1900.10108@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >>> wrote: >>> >>> >>>> Jeff wrote: >>>> >>>> >>>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>>> copy of the comm.api and I've copied the library >>>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>>> into the proper places. When I try to run the application, I get this >>>>>> error... >>>>>> >>>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>>> /usr/lib/libSolarisSerialParallel.so: >>>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>>> little-endian (Possible cause: endianness mismatch) >>>>>> Caught java.lang.UnsatisfiedLinkError: >>>>>> >>>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>>> >>>>>> while loading driver com.sun.comm.SolarisDriver >>>>>> >>>>>> Is there a way around this error? >>>>>> >>>>>> >>>>>> >>>>> What host OS are you running? From your original post it looks like 32 >>>>> bit Linux. >>>>> >>>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>>> depending on the underlying hardware architecture as well. >>>>> >>>>> >>>>> >>>>> >>>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>>> >>>> >>>> >>> I don't think Sun did binary libraries for Linux in the 2.0 version. >>> Can someone with more historical experience than I confirm that? >>> >>> I recently tried to port a Comm API application from Solaris sparc to >>> Linux x86 and likewise could not get my hands on the binary libraries. >>> I eventually just re-wrote the code to use the gnu namespace packages >>> and rxtx 2.1. >>> >>> What I don't understand is why your application vendor does not >>> provide everything you need to run their software. >>> >>> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >>> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >>> /usr/java/default which is actually a softlink to >>> /usr/java/jre1.6.0_05. >>> >>> >>> >> Jeff, >> >> I would like for my vendor to switch to rxtx 2.1. It would make things much >> easier for me. I'm not sure why he's still using the javax compatible code. >> He's a small operation. Re-writing the code to use gnu namespace sounds like >> a major overhaul. Was it? >> > > I found it quite easy. In fact, in order to accommodate the > transition, I actually separated all of the code that deals directly > with the Comm API or RXTX into a helper class. The helper class was > then coded to use reflection to determine which library was available > and then instantiate the necessary objects. No direct imports of > either library are used. The main application just needs to get it's > hands on the IO streams and need not deal directly with the libraries. > Other programs may not be so simple... > > But this doesn't really help you unless your vendor forks over the > source code... > > Jeff, This may not help me directly, but I'm going to forward this thread to the vendor. I think he'll be open to making things work. Thanks again, Rick Knight From agusmunioz at gmail.com Thu Aug 7 16:39:51 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Thu, 7 Aug 2008 19:39:51 -0300 Subject: [Rxtx] How to send ack? Message-ID: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Hi, I'm still learning about serial communication and I have some doubts. I've got this question about how to do the following thing in rxtx. I have this hardware that connect to a PC using a serial port. These hardware receives data from a telephone line, proccess it, and then send it forward to the serial port. I've used a program named wincomm that shows what information is send it through the serial port and I have the nex behaviour: The hardware has a buffer where all data is stored, that cannot be sent it through the seria port. The program reads the first data send it by the hardware, and keep reading the same data always. There is a button in the application that says enable Ack, and when I click, then the hardware start to send all the stored information, and all the information is shown. I write a class, using rxtx that reads the serial port, and the same thing happens, it remains reading the same (first) data all the time. And I thing something like the enable Ack I'm missing. How can I do this enable Ack from my java code using rxtx? Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080807/e0a0f9a1/attachment-0017.html From ajmas at sympatico.ca Thu Aug 7 18:26:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 7 Aug 2008 20:26:41 -0400 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: <4BF42297-81E2-4BB8-A89F-1D43588379AE@sympatico.ca> On 6-Aug-08, at 19:40 , Bruce Boyes wrote: >> Unless I have missed the documentation for RXTX? I javadocced the >> RXTX >> source but information (to me) is minimal. >> Somewhere I got the impression that the Sun Comm API docs is, or was, >> compatible with RXTX, what is the best docs to use in conjuntion >> with RXTX >> and where may the be available? > > Yeah, this is one of my concerns/beefs. There is little documentation > for RXTX and it isn't just the same as javaxcomm. > > I would be willing to help out writing docs for RXTX! Yes really... > esp if we can fix the Bluetooth issues. If you want to contribute documentation then the best place to do that is the wiki. If there is anything missing or that could be improved on then please do so. If there are any points that you would like to see improved, for which you don't have the knowledge then ask on the mailing list for a volunteer. Andre From florianmanschwetus at gmx.de Fri Aug 8 03:04:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Fri, 08 Aug 2008 11:04:14 +0200 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Message-ID: <489C0C0E.2020401@gmx.de> Agustin Mu?oz schrieb: > Hi, I'm still learning about serial communication and I have some > doubts. I've got this question about how to do the following thing in rxtx. > I have this hardware that connect to a PC using a serial port. These > hardware receives data from a telephone line, proccess it, and then send > it forward to the serial port. I've used a program named wincomm that > shows what information is send it through the serial port and I have the > nex behaviour: > > The hardware has a buffer where all data is stored, that cannot be sent > it through the seria port. > The program reads the first data send it by the hardware, and keep > reading the same data always. > There is a button in the application that says enable Ack, and when I > click, then the hardware start to send all the stored information, and > all the information is shown. > > I write a class, using rxtx that reads the serial port, and the same > thing happens, it remains reading the same (first) data all the time. > And I thing something like the enable Ack I'm missing. > How can I do this enable Ack from my java code using rxtx? Afaik, a look at man ascii reveals: Okt Dez Hex Char 006 6 06 ACK So, i hope this will do the job: send(6); florian > > Thanks in advance > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/5b4965f8/attachment-0017.bin From agusmunioz at gmail.com Fri Aug 8 16:31:00 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 19:31:00 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <489C0C0E.2020401@gmx.de> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> Message-ID: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Hi Florian, thanks for the answer. By send(6) you mean to get the port OutputStream and write a 6? I try that but it didn't work. Any suggestion? Thanks On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < florianmanschwetus at gmx.de> wrote: > Agustin Mu?oz schrieb: > > Hi, I'm still learning about serial communication and I have some doubts. >> I've got this question about how to do the following thing in rxtx. >> I have this hardware that connect to a PC using a serial port. These >> hardware receives data from a telephone line, proccess it, and then send it >> forward to the serial port. I've used a program named wincomm that shows >> what information is send it through the serial port and I have the nex >> behaviour: >> >> The hardware has a buffer where all data is stored, that cannot be sent >> it through the seria port. >> The program reads the first data send it by the hardware, and keep reading >> the same data always. >> There is a button in the application that says enable Ack, and when I >> click, then the hardware start to send all the stored information, and all >> the information is shown. >> >> I write a class, using rxtx that reads the serial port, and the same thing >> happens, it remains reading the same (first) data all the time. And I thing >> something like the enable Ack I'm missing. >> How can I do this enable Ack from my java code using rxtx? >> > Afaik, a look at man ascii reveals: > Okt Dez Hex Char > 006 6 06 ACK > So, i hope this will do the job: > send(6); > > florian > >> >> Thanks in advance >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/7f3fba42/attachment-0016.html From agusmunioz at gmail.com Fri Aug 8 18:39:27 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 21:39:27 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Message-ID: <988288430808081739x7f9e7889id82591d5a9e2b4f6@mail.gmail.com> Ok, Florian, it works!! my problem was that I've been sending, through the OutputStream, the bytes of 6 as a string: out.write("6".getBytes()); but then I realized that you can write an int on an OuptuStream, so I tried that and It works: out.write(6); Thank you for the guidance!! On Fri, Aug 8, 2008 at 7:31 PM, Agustin Mu?oz wrote: > Hi Florian, thanks for the answer. By send(6) you mean to get the port > OutputStream and write a 6? > > I try that but it didn't work. > > Any suggestion? > > Thanks > > > On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < > florianmanschwetus at gmx.de> wrote: > >> Agustin Mu?oz schrieb: >> >> Hi, I'm still learning about serial communication and I have some doubts. >>> I've got this question about how to do the following thing in rxtx. >>> I have this hardware that connect to a PC using a serial port. These >>> hardware receives data from a telephone line, proccess it, and then send it >>> forward to the serial port. I've used a program named wincomm that shows >>> what information is send it through the serial port and I have the nex >>> behaviour: >>> >>> The hardware has a buffer where all data is stored, that cannot be sent >>> it through the seria port. >>> The program reads the first data send it by the hardware, and keep >>> reading the same data always. >>> There is a button in the application that says enable Ack, and when I >>> click, then the hardware start to send all the stored information, and all >>> the information is shown. >>> >>> I write a class, using rxtx that reads the serial port, and the same >>> thing happens, it remains reading the same (first) data all the time. And I >>> thing something like the enable Ack I'm missing. >>> How can I do this enable Ack from my java code using rxtx? >>> >> Afaik, a look at man ascii reveals: >> Okt Dez Hex Char >> 006 6 06 ACK >> So, i hope this will do the job: >> send(6); >> >> florian >> >>> >>> Thanks in advance >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/b918ab3d/attachment-0016.html From florianmanschwetus at gmx.de Sat Aug 9 00:45:43 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Sat, 09 Aug 2008 08:45:43 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4899667C.6010706@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> Message-ID: <489D3D17.9090209@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >> Florian Manschwetus wrote: >>> Ok, sounds fine for the receiving problem. >>> But why i have to wait after each byte when sending a command squence? >>> (the for loop in send command) >> >> Hi Florian, >> I'd imagine you probably don't! You could send all bytes in one go and >> RXTX would send them. The problem is most probably the other end: >> perhaps it has a really small buffer, some non-standard UART, or a >> crazy timing issue. If you attach a terminal to your output and send >> all the bytes of a command in one go they should appear no problem. >> >> Regards, >> Michael Erskine. >> > correct with a terminal on the other end it works, my idea was that this > basic baud has some influence. Could some one explain what it is for? > > Florian To make it more clear, my problem is that i can't use: outputStream.write(byte[]); => Beamer doesn't understand the sequence. (mostly no answer when he answers then *001) when i use this construct instead: for (int i = 0; i < command.length; i++) { this.outputStream.write(command[i]); try { Thread.sleep(25); } catch (InterruptedException e) { // TODO Auto-generated catch block e.printStackTrace(); } } it works nearly reliable. So what could it be? This Basic Baud is what exactly? Florian -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080809/692304ee/attachment-0016.bin From tjarvi at qbang.org Sat Aug 9 16:37:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Aug 2008 16:37:19 -0600 (MDT) Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489D3D17.9090209@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> <489D3D17.9090209@gmx.de> Message-ID: On Sat, 9 Aug 2008, Florian Manschwetus wrote: > Florian Manschwetus schrieb: >> Michael Erskine schrieb: >>> Florian Manschwetus wrote: >>>> Ok, sounds fine for the receiving problem. >>>> But why i have to wait after each byte when sending a command squence? >>>> (the for loop in send command) >>> >>> Hi Florian, >>> I'd imagine you probably don't! You could send all bytes in one go and >>> RXTX would send them. The problem is most probably the other end: perhaps >>> it has a really small buffer, some non-standard UART, or a crazy timing >>> issue. If you attach a terminal to your output and send all the bytes of a >>> command in one go they should appear no problem. >>> >>> Regards, >>> Michael Erskine. >>> >> correct with a terminal on the other end it works, my idea was that this >> basic baud has some influence. Could some one explain what it is for? >> >> Florian > To make it more clear, > my problem is that i can't use: > outputStream.write(byte[]); > => Beamer doesn't understand the sequence. (mostly no answer when he answers > then *001) > > when i use this construct instead: > > for (int i = 0; i < command.length; i++) { > this.outputStream.write(command[i]); > try { > Thread.sleep(25); > } catch (InterruptedException e) { > // TODO Auto-generated catch block > e.printStackTrace(); > } > } > > it works nearly reliable. > > So what could it be? This Basic Baud is what exactly? > I suspect you are using the 'moon protocol' and don't know it. RXTX enables this by default. The buffer on the other end is first in first out while reading. If the buffer is full, the bits are hand carried to the moon and burried. Then if the other side reads a couple bytes, two more bytes go into the buffer followed by more moon protocol. The resulting array of bytes the other side reads may appear to be scrambled until you go to the moon, get the bits and insert them in the right place. Flow control can prevent the default moon protocol and throttles the communiation by almost writing a byte at a time as need be. Hardware flow control is preferable but software flow control should also work. Read and write can appear to hang if the other side is not connected. This is why we don't enable them all the time. If you can't use flow control, you have to take care with the moon protocol and give the other side time to read. That is what your slower version of write is doing. -- Trent Jarvi tjarvi at qbang.org From rxtx at allenjb.me.uk Mon Aug 11 08:06:36 2008 From: rxtx at allenjb.me.uk (AllenJB) Date: Mon, 11 Aug 2008 15:06:36 +0100 Subject: [Rxtx] Disabling EV_RXFLAG Message-ID: <48A0476C.2090800@allenjb.me.uk> Hi all, I'm working with a device which does not use an EvtChar and need to disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an event mask of FD 01 00 00. The reference software I have uses FB 00 00 00. With the rxtx mask I get framing errors which I believe are caused when the EvtChar is received. Is there currently a way with rxtx (I've using rxtx from Java) to disable EV_RXFLAG? If not from Java, where would I start if I wanted to turn the EV_RXFLAG option off in the C code? I've had a grep of the rxtx source code, but I can't see where EV_RXFLAG is being set. Thanks in advance, AllenJB From tjarvi at qbang.org Mon Aug 11 14:17:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Aug 2008 14:17:27 -0600 (MDT) Subject: [Rxtx] Disabling EV_RXFLAG In-Reply-To: <48A0476C.2090800@allenjb.me.uk> References: <48A0476C.2090800@allenjb.me.uk> Message-ID: On Mon, 11 Aug 2008, AllenJB wrote: > Hi all, > > I'm working with a device which does not use an EvtChar and need to > disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an > event mask of FD 01 00 00. The reference software I have uses FB 00 00 > 00. With the rxtx mask I get framing errors which I believe are caused > when the EvtChar is received. > > Is there currently a way with rxtx (I've using rxtx from Java) to > disable EV_RXFLAG? > > If not from Java, where would I start if I wanted to turn the EV_RXFLAG > option off in the C code? I've had a grep of the rxtx source code, but I > can't see where EV_RXFLAG is being set. > > Thanks in advance, > > AllenJB Hi Allen, I'd look at termios.c::tcsetattr() and termios.c::FillDCB() -- Trent Jarvi tjarvi at qbang.org From superdadusa at gmail.com Tue Aug 12 13:57:32 2008 From: superdadusa at gmail.com (John Choi) Date: Tue, 12 Aug 2008 13:57:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. Message-ID: Hi all, Just let you all know I just start to learn Java. I have download the serial comm package and the source code from open source communities.. I was able to verify with the given message string via serial monitor. when the given message string sends to the serial port then the character return added to the end of string by default if I use "Hello World" however if I changed to something else other than "Hello, World" there is no character return add to the end of string. I thing the library download from rxtx.org has implemented for the special strings. I can do like "login\n" in the string message to make character return but I don't want to add this individual custom character for each command return in every static message string I send, Can any who have done this might help me? Basically, something like this,, Write and add function to the program write a command, Reads the respond from a serial device.. Function handles multiple messages, Write: "com open" Read: Welcome to my world" expected Write: "admin" Read: Password?, expected Write: "admin" Read: you are successfully login terminal, expected. And I need to add a separate function handler handles a character return add to the each command above. If anyone can help this I can do the reset? Thank you in advance, John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0012.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SerialIO.java Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0012.pl From Steffen.DETTMER at ingenico.com Wed Aug 13 02:16:38 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 13 Aug 2008 10:16:38 +0200 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: References: Message-ID: <20080813081638.GA25412@elberon.bln.de.ingenico.com> * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > I can do like "login\n" in the string message to make character > return but I don't want to add this individual custom character > for each command return in every static message string I send, and why not?! > Can any who have done this might help me? what's about with writing a small wrapper function adding the carriage return? However, this would be slow, because either you call write two times (very bad) or the string needs to be copied, \n appended and written (since you are using Java Performance probably isn't so critical). Personally I would write `"login\n"' and `username + "\n"' etc., because since it is part of the command it should be part of the command definition string. > Basically, something like this,, Write and add function to the program write > a command, Reads the respond from a serial device.. correctly reading a `line' is more difficult. If you cannot make assumptions about timeouts and/or you need to have low delay, you need to read byte wise. If you need to save CPU resources you might need to add some buffering layer that you can read byte-wise but that is reading blockwise with some small timeout (lets say for serial lines something around byte transmission time times three or so). > /* > * To change this template, choose Tools | Templates > * and open the template in the editor. > */ :) > package joliba; > > /** > * > * @author root > */ :) > // derived from SUN's examples in the javax.comm package > import java.io.*; > import java.util.*; > //import javax.comm.*; // for SUN's serial/parallel port libraries > import gnu.io.*; // for rxtxSerial library > > public class SerialIO implements Runnable, SerialPortEventListener { > static CommPortIdentifier portId; > static CommPortIdentifier saveportId; > static Enumeration portList; > InputStream inputStream; > SerialPort serialPort; > Thread readThread; You need a thread for your synchronous RPC-style protocol? > static String messageString = "Hello, world!"; > static OutputStream outputStream; > static boolean outputBufferEmptyFlag = false; > > public static void main(String[] args) { > boolean portFound = false; > String defaultPort; > > // determine the name of the serial port on several operating systems > String osname = System.getProperty("os.name","").toLowerCase(); > if ( osname.startsWith("windows") ) { > // windows > defaultPort = "COM1"; > } else if (osname.startsWith("linux")) { > // linux > defaultPort = "/dev/ttyS0"; > } else if ( osname.startsWith("mac") ) { > // mac > defaultPort = "????"; > } else { > System.out.println("Sorry, your operating system is not supported"); > return; > } Is such a construction recommended? Isn't there some abstraction (like COM1 working on any platform)? [...] > try { > // activate the OUTPUT_BUFFER_EMPTY notifier > serialPort.notifyOnOutputEmpty(true); > } catch (Exception e) { > System.out.println("Error setting event notification"); > System.out.println(e.toString()); > System.exit(-1); > } I doubt that -1 is defined, probably some 127 or so would be the result, maybe better simply `throw e'? > public void writetoport() { > System.out.println("Writing \""+messageString+"\" to "+serialPort.getName()); > try { > // write string to serial port > outputStream.write(messageString.getBytes()); > } catch (IOException e) {} > } maybe something like /** * Writes the given output string and an additional carriage * return to the current outputStream. */ public void writeStringToPort( /** The output string (without CR). */ String output ) throws IOException { String outputLine = output + "\n"; outputStream.write(outputLine.getBytes()); } ? > > public SerialIO() { > // initalize serial port > try { > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > } catch (PortInUseException e) {} if the port is in use, you continue? Wonder that this works in Java, I would assume serialPort beeing uninitialized which AFAIK is an error in Java. > try { > inputStream = serialPort.getInputStream(); > } catch (IOException e) {} > > try { > serialPort.addEventListener(this); > } catch (TooManyListenersException e) {} > > // activate the DATA_AVAILABLE notifier > serialPort.notifyOnDataAvailable(true); > > try { > // set port parameters > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > } catch (UnsupportedCommOperationException e) {} > > // start the read thread > readThread = new Thread(this); > readThread.start(); > > } I think in all those exception cases you can abort, because it is unlikely that ignoring those errors allow a successful continuation, so in this case maybe it would be better to add a throw clause to the method. > public void run() { > // first thing in the thread, we initialize the write operation > initwritetoport(); > try { > while (true) { > // write string to port, the serialEvent will read it > writetoport(); > Thread.sleep(1000); > } > } catch (InterruptedException e) {} > } Does this make sense? Your `SimpleReadApp' writes one and the same string each second? > public void serialEvent(SerialPortEvent event) { > switch (event.getEventType()) { > case SerialPortEvent.BI: > case SerialPortEvent.OE: > case SerialPortEvent.FE: > case SerialPortEvent.PE: > case SerialPortEvent.CD: > case SerialPortEvent.CTS: > case SerialPortEvent.DSR: > case SerialPortEvent.RI: > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > break; > case SerialPortEvent.DATA_AVAILABLE: > // we get here if data has been received > byte[] readBuffer = new byte[20]; > try { > // read data > while (inputStream.available() > 0) { > int numBytes = inputStream.read(readBuffer); > } > // print data > String result = new String(readBuffer); > System.out.println("Read: "+result); > } catch (IOException e) {} I doubt that this is correct. I would assume you will get a 20 bytes result always, if more bytes would be available they would be printed in a second line but if less bytes are read I'd assume that the buffer/result contains zero bytes from implicite readBuffer contents initialisation (zero is no string terminator in Java AFAIK). > break; > } > } > } oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From florianmanschwetus at gmx.de Wed Aug 13 06:09:31 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 13 Aug 2008 14:09:31 +0200 Subject: [Rxtx] someone has seen such errors? Message-ID: <48A2CEFB.90007@gmx.de> I mean my communication mostly works, but it is far from perfect could this be the reason? Florian Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/949b9947/attachment-0012.bin From superdadusa at gmail.com Wed Aug 13 08:40:32 2008 From: superdadusa at gmail.com (John Choi) Date: Wed, 13 Aug 2008 08:40:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: <20080813081638.GA25412@elberon.bln.de.ingenico.com> References: <20080813081638.GA25412@elberon.bln.de.ingenico.com> Message-ID: Thank you so much Steffen and I will try that suggestion. John On 8/13/08, Steffen DETTMER wrote: > > * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > > I can do like "login\n" in the string message to make character > > return but I don't want to add this individual custom character > > for each command return in every static message string I send, > > and why not?! > > > Can any who have done this might help me? > > what's about with writing a small wrapper function adding the > carriage return? > However, this would be slow, because either you call write two > times (very bad) or the string needs to be copied, \n appended > and written (since you are using Java Performance probably isn't > so critical). > > Personally I would write `"login\n"' and `username + "\n"' etc., > because since it is part of the command it should be part of the > command definition string. > > > Basically, something like this,, Write and add function to the program > write > > a command, Reads the respond from a serial device.. > > correctly reading a `line' is more difficult. If you cannot make > assumptions about timeouts and/or you need to have low delay, you > need to read byte wise. If you need to save CPU resources you > might need to add some buffering layer that you can read > byte-wise but that is reading blockwise with some small timeout > (lets say for serial lines something around byte transmission > time times three or so). > > > /* > > * To change this template, choose Tools | Templates > > * and open the template in the editor. > > */ > > :) > > > package joliba; > > > > /** > > * > > * @author root > > */ > > :) > > > // derived from SUN's examples in the javax.comm package > > import java.io.*; > > import java.util.*; > > //import javax.comm.*; // for SUN's serial/parallel port libraries > > import gnu.io.*; // for rxtxSerial library > > > > public class SerialIO implements Runnable, SerialPortEventListener { > > static CommPortIdentifier portId; > > static CommPortIdentifier saveportId; > > static Enumeration portList; > > InputStream inputStream; > > SerialPort serialPort; > > Thread readThread; > > You need a thread for your synchronous RPC-style protocol? > > > static String messageString = "Hello, world!"; > > static OutputStream outputStream; > > static boolean outputBufferEmptyFlag = false; > > > > public static void main(String[] args) { > > boolean portFound = false; > > String defaultPort; > > > > // determine the name of the serial port on several operating > systems > > String osname = System.getProperty("os.name","").toLowerCase(); > > if ( osname.startsWith("windows") ) { > > // windows > > defaultPort = "COM1"; > > } else if (osname.startsWith("linux")) { > > // linux > > defaultPort = "/dev/ttyS0"; > > } else if ( osname.startsWith("mac") ) { > > // mac > > defaultPort = "????"; > > } else { > > System.out.println("Sorry, your operating system is not > supported"); > > return; > > } > > Is such a construction recommended? Isn't there some abstraction > (like COM1 working on any platform)? > > [...] > > try { > > // activate the OUTPUT_BUFFER_EMPTY notifier > > serialPort.notifyOnOutputEmpty(true); > > } catch (Exception e) { > > System.out.println("Error setting event notification"); > > System.out.println(e.toString()); > > System.exit(-1); > > } > > I doubt that -1 is defined, probably some 127 or so would be the > result, maybe better simply `throw e'? > > > public void writetoport() { > > System.out.println("Writing \""+messageString+"\" to > "+serialPort.getName()); > > try { > > // write string to serial port > > outputStream.write(messageString.getBytes()); > > } catch (IOException e) {} > > } > > maybe something like > > /** > * Writes the given output string and an additional carriage > * return to the current outputStream. > */ > public void > writeStringToPort( > /** The output string (without CR). */ > String output > ) throws IOException > { > String outputLine = output + "\n"; > outputStream.write(outputLine.getBytes()); > } > > ? > > > > > public SerialIO() { > > // initalize serial port > > try { > > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > > } catch (PortInUseException e) {} > > if the port is in use, you continue? Wonder that this works in > Java, I would assume serialPort beeing uninitialized which AFAIK > is an error in Java. > > > try { > > inputStream = serialPort.getInputStream(); > > } catch (IOException e) {} > > > > try { > > serialPort.addEventListener(this); > > } catch (TooManyListenersException e) {} > > > > // activate the DATA_AVAILABLE notifier > > serialPort.notifyOnDataAvailable(true); > > > > try { > > // set port parameters > > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > } catch (UnsupportedCommOperationException e) {} > > > > // start the read thread > > readThread = new Thread(this); > > readThread.start(); > > > > } > > I think in all those exception cases you can abort, because it is > unlikely that ignoring those errors allow a successful > continuation, so in this case maybe it would be better to add a > throw clause to the method. > > > public void run() { > > // first thing in the thread, we initialize the write operation > > initwritetoport(); > > try { > > while (true) { > > // write string to port, the serialEvent will read it > > writetoport(); > > Thread.sleep(1000); > > } > > } catch (InterruptedException e) {} > > } > > Does this make sense? Your `SimpleReadApp' writes one and the > same string each second? > > > public void serialEvent(SerialPortEvent event) { > > switch (event.getEventType()) { > > case SerialPortEvent.BI: > > case SerialPortEvent.OE: > > case SerialPortEvent.FE: > > case SerialPortEvent.PE: > > case SerialPortEvent.CD: > > case SerialPortEvent.CTS: > > case SerialPortEvent.DSR: > > case SerialPortEvent.RI: > > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > > break; > > case SerialPortEvent.DATA_AVAILABLE: > > // we get here if data has been received > > byte[] readBuffer = new byte[20]; > > try { > > // read data > > while (inputStream.available() > 0) { > > int numBytes = inputStream.read(readBuffer); > > } > > // print data > > String result = new String(readBuffer); > > System.out.println("Read: "+result); > > } catch (IOException e) {} > > I doubt that this is correct. I would assume you will get a 20 > bytes result always, if more bytes would be available they would > be printed in a second line but if less bytes are read I'd assume > that the buffer/result contains zero bytes from implicite > readBuffer contents initialisation (zero is no string terminator > in Java AFAIK). > > > break; > > } > > } > > } > > oki, > > Steffen > > About Ingenico Throughout the world businesses rely on Ingenico for secure > and expedient electronic transaction acceptance. Ingenico products leverage > proven technology, established standards and unparalleled ergonomics to > provide optimal reliability, versatility and usability. This comprehensive > range of products is complemented by a global array of services and > partnerships, enabling businesses in a number of vertical sectors to accept > transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged > information. If you are not the addressee or authorized to receive this for > the addressee, you must not use, copy, disclose or take any action based on > this message or any information herein. If you have received this message in > error, please advise the sender immediately by reply e-mail and delete this > message. Thank you for your cooperation. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/73c4135c/attachment-0011.html From ajmas at sympatico.ca Sat Aug 16 07:15:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 09:15:41 -0400 Subject: [Rxtx] someone has seen such errors? In-Reply-To: <48A2CEFB.90007@gmx.de> References: <48A2CEFB.90007@gmx.de> Message-ID: <43B5E8DA-1D93-4D90-809B-AAF35FF724C5@sympatico.ca> On 13-Aug-08, at 08:09 , Florian Manschwetus wrote: > I mean my communication mostly works, but it is far from perfect > could this be the reason? > > Florian > > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control Judging by the error messages this looks related to the driver you are using. Do a search for the following string with you favourite search engine, it should turn up a few hits: ftdi_set_termios FAILED to set databits/stopbits/parity Andre From ajmas at sympatico.ca Sat Aug 16 19:12:04 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 21:12:04 -0400 Subject: [Rxtx] Using SerialPortEvent? Message-ID: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Hi, Could someone tell me how I should be using the SerialPortEvent? Am I meant to be waiting for data and then simply reading from the inputstream? If this is the case why no just block on an inputstream read? Andr? From tjarvi at qbang.org Sat Aug 16 19:41:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 16 Aug 2008 19:41:13 -0600 (MDT) Subject: [Rxtx] Using SerialPortEvent? In-Reply-To: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> References: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Message-ID: On Sat, 16 Aug 2008, Andre-John Mas wrote: > Hi, > > Could someone tell me how I should be using the SerialPortEvent? Am I > meant to be waiting for data and then simply reading from the > inputstream? If this is the case why no just block on an inputstream > read? > Polling for data is fine also. It really depends upon what you are trying to do. For instance, if you require x bytes before reading, you can start polling after data is available. If you read on the same thread as your GUI and are waiting for data in a read, the results may be less than desirable. Java programming is 'usually' event driven rather than polling based. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sat Aug 16 20:10:39 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 22:10:39 -0400 Subject: [Rxtx] Using SerialPortEvent? In-Reply-To: References: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Message-ID: <3E495D4C-BB28-4845-A6AB-984C9A826BDF@sympatico.ca> On 16-Aug-08, at 21:41 , Trent Jarvi wrote: > On Sat, 16 Aug 2008, Andre-John Mas wrote: > >> Hi, >> >> Could someone tell me how I should be using the SerialPortEvent? Am I >> meant to be waiting for data and then simply reading from the >> inputstream? If this is the case why no just block on an inputstream >> read? >> > > Polling for data is fine also. It really depends upon what you are > trying to do. For instance, if you require x bytes before reading, > you can start polling after data is available. If you read on the > same thread as your GUI and are waiting for data in a read, the > results may be less than desirable. > > Java programming is 'usually' event driven rather than polling based. Sounds good. I thought I would use this opportunity to provide a event based version of the TwoWaySerialComm example. Could you just validate it before I add it to the Wiki: package ajmas74.experimental; import gnu.io.CommPort; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; import gnu.io.SerialPortEvent; import gnu.io.SerialPortEventListener; import java.io.IOException; import java.io.InputStream; import java.io.OutputStream; /** * This version of the TwoWaySerialComm example makes use of the * SerialPortEventListener to avoid polling. * * @author ajmas * */ public class TwoWaySerialComm { public TwoWaySerialComm() { super(); } void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { CommPort commPort = portIdentifier.open(this.getClass().getName(),2000); if ( commPort instanceof SerialPort ) { SerialPort serialPort = (SerialPort) commPort; serialPort .setSerialPortParams (57600 ,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); (new Thread(new SerialWriter(out))).start(); serialPort.addEventListener(new SerialReader(in)); } else { System.out.println("Error: Only serial ports are handled by this example."); } } } /** * Handles the input coming from the serial port. A new line character * is treated as the end of a block in this example. */ public static class SerialReader implements SerialPortEventListener { private InputStream in; private byte[] buffer = new byte[1024]; public SerialReader ( InputStream in ) { this.in = in; } public void serialEvent(SerialPortEvent arg0) { int data; try { int len = 0; while ( ( data = in.read()) > -1 ) { if ( data != '\n' ) { break; } buffer[len++] = (byte) data; } System.out.print(new String(buffer,0,len)); } catch ( IOException e ) { e.printStackTrace(); System.exit(-1); } } } /** */ public static class SerialWriter implements Runnable { OutputStream out; public SerialWriter ( OutputStream out ) { this.out = out; } public void run () { try { int c = 0; while ( ( c = System.in.read()) > -1 ) { this.out.write(c); } } catch ( IOException e ) { e.printStackTrace(); System.exit(-1); } } } public static void main ( String[] args ) { try { (new TwoWaySerialComm()).connect("COM3"); } catch ( Exception e ) { e.printStackTrace(); } } } From lfarkas at lfarkas.org Tue Aug 19 07:32:59 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Tue, 19 Aug 2008 15:32:59 +0200 Subject: [Rxtx] JNI or CNI Message-ID: <48AACB8B.9060606@lfarkas.org> hi, what is the current recommended way to rxtx on linux JNI or it's better to use CNI? is the CNI version fully functional and the same level as the JNI? i currently try to make a rhel/centos/fedora rpm for rxtx but has many problems with the standard dir structure. yours. -- Levente "Si vis pacem para bellum!" From lfarkas at lfarkas.org Tue Aug 19 08:47:34 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Tue, 19 Aug 2008 16:47:34 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel Message-ID: <48AADD06.7040809@lfarkas.org> hi, newer or not so newer linux kernel do not contain the UTS_RELEASE so the current rxtx is not compile on the latest kernels. even if it's commented out in the cvs configure there are other places. i attcahed a patch which fix it (or at least doesn't cause error at non-debug build). ps. is there any plan to the new 2.1-8 release in the near future? there are many changes (at least the license change in all file and in this case create a diff is very difficult)? the latest release more then 2 years old:-( -- Levente "Si vis pacem para bellum!" -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-2.1-uts.patch Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080819/ab5d38ac/attachment-0005.pl From ajmas at sympatico.ca Tue Aug 19 16:21:53 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 19 Aug 2008 18:21:53 -0400 Subject: [Rxtx] Event based example Message-ID: <24735BFB-B088-4B84-8173-FE98DF63B12F@sympatico.ca> Hi, I have just posted an example of using SerialPortEventListener in the Wiki: http://rxtx.qbang.org/wiki/index.php/Event_Based_Two_Way_Communication If you see any issues please could you let me know, or makes the changes. Andre From Martin.Oberhuber at windriver.com Fri Aug 22 04:02:24 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 22 Aug 2008 12:02:24 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <48AADD06.7040809@lfarkas.org> References: <48AADD06.7040809@lfarkas.org> Message-ID: <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> Farkas, there are indeed efforts to get a new RXTX release out the door. Your experience as a package maintainer would likely be helpful during these efforts, since I'd think it makes sense to keep the patches minimal that you must make to have the source compile in your environment. What are the things that you find problematic, apart from the UTS thing that you have mentioned before? What is the timing that you have in mind for your package? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Farkas Levente > Sent: Tuesday, August 19, 2008 4:48 PM > To: rxtx at qbang.org > Subject: [Rxtx] UTS_RELEASE not defined in newer kernel > > hi, > newer or not so newer linux kernel do not contain the > UTS_RELEASE so the > current rxtx is not compile on the latest kernels. even if it's > commented out in the cvs configure there are other places. > i attcahed a patch which fix it (or at least doesn't cause error at > non-debug build). > > ps. is there any plan to the new 2.1-8 release in the near > future? there > are many changes (at least the license change in all file and in this > case create a diff is very difficult)? the latest release more then 2 > years old:-( > > -- > Levente "Si vis pacem para bellum!" > From lfarkas at lfarkas.org Fri Aug 22 04:36:26 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Fri, 22 Aug 2008 12:36:26 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> References: <48AADD06.7040809@lfarkas.org> <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> Message-ID: <48AE96AA.6090505@lfarkas.org> hi, the packages already build for fedora-9 and centos-5 and here: http://www.lfarkas.org/linux/packages/ what i've to patch, the UTS, the configure script, but it's already fixed in the cvs (in another way) and the loadlibrary. the reasons for last one can be found here: https://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_files_that_use_JNI after we test it i'd like to add these packages to fedora and epel main repository (that's why it's be useful a new release after 2 years:-) imho versions are cheap and why not just release 2.1-8? the real code changes are minimal and if something critical bug found still can release 2.1-9:-) ps. and would be better to use simple number for version like 2.1-7 rather then 2.1-7v2. Oberhuber, Martin wrote: > Farkas, > > there are indeed efforts to get a new RXTX release out the > door. Your experience as a package maintainer would likely > be helpful during these efforts, since I'd think it makes > sense to keep the patches minimal that you must make to > have the source compile in your environment. > > What are the things that you find problematic, apart from > the UTS thing that you have mentioned before? > > What is the timing that you have in mind for your package? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >> On Behalf Of Farkas Levente >> Sent: Tuesday, August 19, 2008 4:48 PM >> To: rxtx at qbang.org >> Subject: [Rxtx] UTS_RELEASE not defined in newer kernel >> >> hi, >> newer or not so newer linux kernel do not contain the >> UTS_RELEASE so the >> current rxtx is not compile on the latest kernels. even if it's >> commented out in the cvs configure there are other places. >> i attcahed a patch which fix it (or at least doesn't cause error at >> non-debug build). >> >> ps. is there any plan to the new 2.1-8 release in the near >> future? there >> are many changes (at least the license change in all file and in this >> case create a diff is very difficult)? the latest release more then 2 >> years old:-( >> >> -- >> Levente "Si vis pacem para bellum!" >> -- Levente "Si vis pacem para bellum!" From tjarvi at qbang.org Fri Aug 22 18:50:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Aug 2008 18:50:32 -0600 (MDT) Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <48AE96AA.6090505@lfarkas.org> References: <48AADD06.7040809@lfarkas.org> <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> <48AE96AA.6090505@lfarkas.org> Message-ID: Hi Farkas, The v2 was simply the second build - no code changes. We are comming out with a new release shortly. I would encourage working with distros as you are. The building of rxtx turns out to be a bottle neck in quick releases. We do want stable releases that work for a year or more but I would have no problems with quicker cycles on developing work. I would have no problem working with someone that did builds that receive less testing more often but they do have to come out for multiple platforms from this end. Thanks for the links. On Fri, 22 Aug 2008, Farkas Levente wrote: > hi, > the packages already build for fedora-9 and centos-5 and here: > http://www.lfarkas.org/linux/packages/ > what i've to patch, the UTS, the configure script, but it's already > fixed in the cvs (in another way) and the loadlibrary. the reasons for > last one can be found here: > https://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_files_that_use_JNI > after we test it i'd like to add these packages to fedora and epel main > repository (that's why it's be useful a new release after 2 years:-) > imho versions are cheap and why not just release 2.1-8? the real code > changes are minimal and if something critical bug found still can > release 2.1-9:-) > > ps. and would be better to use simple number for version like 2.1-7 > rather then 2.1-7v2. > > Oberhuber, Martin wrote: >> Farkas, >> >> there are indeed efforts to get a new RXTX release out the >> door. Your experience as a package maintainer would likely >> be helpful during these efforts, since I'd think it makes >> sense to keep the patches minimal that you must make to >> have the source compile in your environment. >> >> What are the things that you find problematic, apart from >> the UTS thing that you have mentioned before? >> >> What is the timing that you have in mind for your package? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >>> On Behalf Of Farkas Levente >>> Sent: Tuesday, August 19, 2008 4:48 PM >>> To: rxtx at qbang.org >>> Subject: [Rxtx] UTS_RELEASE not defined in newer kernel >>> >>> hi, >>> newer or not so newer linux kernel do not contain the >>> UTS_RELEASE so the >>> current rxtx is not compile on the latest kernels. even if it's >>> commented out in the cvs configure there are other places. >>> i attcahed a patch which fix it (or at least doesn't cause error at >>> non-debug build). >>> >>> ps. is there any plan to the new 2.1-8 release in the near >>> future? there >>> are many changes (at least the license change in all file and in this >>> case create a diff is very difficult)? the latest release more then 2 >>> years old:-( >>> >>> -- >>> Levente "Si vis pacem para bellum!" >>> > > > From andy at triera.net Sat Aug 23 15:17:44 2008 From: andy at triera.net (Andy Rozman) Date: Sat, 23 Aug 2008 21:17:44 +0000 Subject: [Rxtx] port not identified on FreeBSD In-Reply-To: References: Message-ID: <48B07E78.2030306@triera.net> Hi ! I have one small problem... I have started using FreeBSD in last few days and I have come accross a problem with rxtx on FreeBSD. I am using usb-to-serial converter, which is identified under FreeBSD without problem as ucom0, and creates link under /dev called ttyU0, which is correct way to be done under FreeBSD (if device would be unidentified it would be called ugen0 - as usb generic). Problem is that I say to rxtx to get my all serial ports this one is not among them. Which names are permissable under linux-like implementations? Which will be accepted as serial ports? Andy From tjarvi at qbang.org Sat Aug 23 13:57:45 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 23 Aug 2008 13:57:45 -0600 (MDT) Subject: [Rxtx] port not identified on FreeBSD In-Reply-To: <48B07E78.2030306@triera.net> References: <48B07E78.2030306@triera.net> Message-ID: On Sat, 23 Aug 2008, Andy Rozman wrote: > Hi ! > > I have one small problem... I have started using FreeBSD in last few > days and I have come accross a problem with rxtx on FreeBSD. > > I am using usb-to-serial converter, which is identified under FreeBSD > without problem as ucom0, and creates link under /dev called > ttyU0, which is correct way to be done under FreeBSD (if device would be > unidentified it would be called ugen0 - as usb generic). Problem is that > I say to rxtx to get my all serial ports this one is not among them. > Which names are permissable under linux-like implementations? Which will > be accepted as serial ports? > > Andy > Thanks Andy! We will add ttyU* to FreeBSD. For now you can use properties to enable the port. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting#How_does_rxtx_detect_ports.3F__Can_I_override_it.3F The fix: diff -u -r1.16.2.59 RXTXCommDriver.java --- RXTXCommDriver.java 18 Nov 2007 22:32:41 -0000 1.16.2.59 +++ RXTXCommDriver.java 23 Aug 2008 19:55:25 -0000 @@ -644,6 +644,7 @@ { String[] Temp = { "ttyd", //general purpose serial ports + "ttyU", //general purpose USB serial ports "cuaa", //dialout serial ports "ttyA", //Specialix SI/XIO dialin ports "cuaA", //Specialix SI/XIO dialout ports -- Trent Jarvi tjarvi at qbang.org From rick_knight at rlknight.com Mon Aug 4 13:25:10 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Mon, 04 Aug 2008 12:25:10 -0700 Subject: [Rxtx] Sun's Comm API? Message-ID: <48975796.4010600@rlknight.com> I have an application that requires the javax compatible version of RXTX and Sun's comm api. I've been able to download and extract the version of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api anywhere. Can someone tell me where I can find it? Or maybe send me a copy? Also, when I try to build RXTX, configure and make complete successfully but make install failes with this error libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 I've never come accross this error before. How can I get past it? Thanks, Rick From bboyes at systronix.com Mon Aug 4 19:10:01 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:10:01 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48975796.4010600@rlknight.com> References: <48975796.4010600@rlknight.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/cb9c6167/attachment-0021.html From bboyes at systronix.com Mon Aug 4 19:12:37 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:12:37 -0600 Subject: [Rxtx] Towards an RXTX release - CSR BT/USB chipset In-Reply-To: <488FB7E7.8000802@gmail.com> References: <460801A4097E3D4CA04CC64EE648584806C56CF0@ism-mail03.corp.ad.wrs.com> <13557-75390@sneakemail.com> <20980-23424@sneakemail.com> <488FB7E7.8000802@gmail.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/52236088/attachment-0021.html From tjarvi at qbang.org Mon Aug 4 19:42:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 19:42:21 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: On Mon, 4 Aug 2008, Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: > I have an application that requires the javax compatible > version of RXTX > and Sun's comm api. I've been able to download and extract > the version > of RXTX that I need (2.0-7pre2) but I can't find Sun's camm > api > anywhere. Can someone tell me where I can find it? Or maybe > send me a > > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm port > support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have just > a ZIP with only the .class JAR file - no source or docs), has a readme > with these comments: > > This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release.? The 2.0.3 release itself is > no longer distributed.? comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project.? The RxTx project (http://www.rxtx.org ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org) was opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support.? Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins.? Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > ? > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > I hope that is helpful! > It would be nice to work with Sun to resolve those longstanding issues. But it may not be practical unless the process goes as fast and painless as the grandfathering of commapi did. Another option may be the old kaffe extensions that moved to gnu classpathx. These don't have the native libraries but should provide the 2.0 interface and the javax.comm.properties mechansim for SPI. http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Mon Aug 4 20:23:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Mon, 04 Aug 2008 20:23:57 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4897B9BD.5070809@ergotech.com> Has there been any work/would it be possible, to layer a javacomm look-alike on top of the GNU code? The goal is not to move the javax code forward, but to emulate the "legacy" javax packages for people who still need this. Jim Trent Jarvi wrote: > On Mon, 4 Aug 2008, Bruce Boyes wrote: > >> At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible >> version of RXTX >> and Sun's comm api. I've been able to download and extract >> the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm >> api >> anywhere. Can someone tell me where I can find it? Or maybe >> send me a >> >> >> javaxcomm has had a sort of on-again off-again history. The windoze >> version has been languishing for years (literally) but there are newer >> versions for other OS's. >> >> We try to keep links on one of our help pages current: >> http://www.practicalembeddedjava.com/tools/javatools_list.html >> which gets you to here: >> http://java.sun.com/products/javacomm/ >> where it says in fact they no longer even support Windows and Mac: >> "Implementations of the API are currently available for Solaris SPARC, >> Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so >> someone could support it. But I guess that's part of the reason RXTX >> exists! >> >> So one of Sun's own products, SunSPOT, has to use RXTX to get comm port >> support. >> >> The version we use is 2.0 from 11/15/1998. I have posted it on our >> website, which is within the terms of the license agreement contained >> therein (as I understand it). >> >> The last version of javaxcomm for Windows, 2.0.3, (for which I have just >> a ZIP with only the .class JAR file - no source or docs), has a readme >> with these comments: >> >> This distribution contains the comm.jar file original part >> of the COMMAPI 2.0.3 release. The 2.0.3 release itself is >> no longer distributed. comm.jar, which contains the comm >> API java class files (eg. Sun's binary implementation of the >> interface classes), is being made available, unsupported, >> with no obligation to fix bugs, at the request of the RXTX >> project. The RxTx project (http://www.rxtx.org ), uses the >> comm.jar class files, but provides their own native library >> components to provide support for other platforms. >> >> The 2.0.3 comm.jar is being provided in this way because >> as of COMMAPI 3.x, the java binary implementation forked and >> became incompatible with the RxTx project's native code. >> Due to the lack of a clear business case, and to resource >> constraints, no additional resources are being >> provided to provide an alternative engineering solution >> at the time of writing. >> >> RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: >> >> Ultimately the COMMAPI would be better served if a Java >> Community Process JSR (http://www.jcp.org) was opened and >> the COMMAPI was rearchitected to provide a more pluggable >> framework to improve cross-platform support. Such an >> architecture would embody a better defined and better >> documented SPI interface, including a way for comm. ports >> to be revealed to the client application through the API >> via platform-aware plugins. Similarly, native code used >> to access comm port in general could be handled more >> flexibly using a plugin model, whereby on any platform, >> multiple native modules could be in use simultaneously. >> >> Since there are now various ways serial ports can be implemented >> and accessed, modular comm. port JNI native libraries would be >> of benefit insofar as removing the burden of over-generalization >> from any single native component, or inversely, by relieving the >> implicit constraint that comm. drivers be accessed only via a >> monolithic mechanism, such as the UNIX vnode interface. >> >> paul.klissner at sun.com >> 6/10/06 >> >> I hope that is helpful! >> > > It would be nice to work with Sun to resolve those longstanding issues. > But it may not be practical unless the process goes as fast and painless > as the grandfathering of commapi did. > > Another option may be the old kaffe extensions that moved to gnu > classpathx. These don't have the native libraries but should provide > the 2.0 interface and the javax.comm.properties mechansim for SPI. > > http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Mon Aug 4 21:09:15 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 21:09:15 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? Message-ID: Hi Jim, I will not step into the javax.comm namespace without Sun's explicite permission. I fully understand the pain point you are trying to address. In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm Linux) - which remains an integral part of rxtx. At the time it was a win for Sun and rxtx. The Sun commapi license is/was fairly clear that rxtx should not step into that namespace. It made sense as Sun was active in that space and rxtx may go into another namespace - it was an experiment in working with Sun. This may sound silly looking at something that happened almost 10 years ago. In a community of respect which Sun helped create, there is no question about what to do. I hope eventually Sun will step up and do a right thing too. I agree that this is hurting the API more than helping it. There are also questions about how to replace the API in the long term which includes HID support which isn't going well so far. Others that can't even look at Sun's javax.comm today and can look at Kaffe's contribution to classpathx can easily work around such restrictions. On Mon, 4 Aug 2008, Jim Redman wrote: > Has there been any work/would it be possible, to layer a javacomm > look-alike on top of the GNU code? > > The goal is not to move the javax code forward, but to emulate the > "legacy" javax packages for people who still need this. > > Jim > > Trent Jarvi wrote: >> >> It would be nice to work with Sun to resolve those longstanding issues. >> But it may not be practical unless the process goes as fast and painless >> as the grandfathering of commapi did. >> >> Another option may be the old kaffe extensions that moved to gnu >> classpathx. These don't have the native libraries but should provide >> the 2.0 interface and the javax.comm.properties mechansim for SPI. >> >> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From florianmanschwetus at gmx.de Tue Aug 5 05:04:46 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 13:04:46 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: References: <48971C1F.9020806@gmx.de> Message-ID: <489833CE.1040801@gmx.de> Just look at sendCommand in this method I have to place a Thread.sleep(20) after each byte send to get working. Even the event based receive doesn't work fine but this could be may stupidness. The specifikation document (it is on the last pages of the manual) for the beamer could be found on: http://www.optoma.co.uk/support.aspx Florian Manschwetus Trent Jarvi schrieb: > > Hi Florian > > Sorry for the top post in advance. I worry you may not see my answer > under all your code :) > > I have not received this email before. This is 500k of code which I > don't have time to read. I can spend about 5 min on each hobby email > and still get to work in the morning. I have a couple suggestions for > how to get an answer. > > First, cut out your comments and extra code so you can demonstrate the > question (I might even glance and see what is wrong then). Don't go for > a working final product. Isolate the problem using a simple program and > then ask with that as an example. If I did what you just did, I'd have > to post 3/4 of a million lines of code :) > > Second, join the rxtx mail-list and ask there. This will give you 100x > more eyes. I'll also read and try to follow. > > -- > taj > > > > On Mon, 4 Aug 2008, Florian Manschwetus wrote: > >> It could be that my university account is blocked by filters so >> resending from here. >> >> >> Topic is to control Optoma HD80 beamer using rs232 serial chat. >> This code is able to detect power state and switch the beamer on / off. >> connected is the beamer using a digitus usb 2.0 serial adapter with an >> FT232 USB-Serial adapter the systems architecture is amd64. >> >> Please take a look in the sendCommand routine i have to place theire >> those Thread.sleep to get it working. >> Now the question is this correct or is there a better way to get this >> working correctly? >> >> In the javadoc coming with the install i found this: >> setBaudBase >> >> public boolean setBaudBase(int BaudBase) >> throws UnsupportedCommOperationException, >> java.io.IOException >> >> Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 >> before using. >> >> could this explain the error? >> I attached my java source and the protocol description for the beamer >> (available on vendor website). >> >> thx, >> Florian Manschwetus >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: TestRS232.java Type: text/x-java Size: 9143 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0042.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0043.bin From michael.erskine at ketech.com Tue Aug 5 05:53:49 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Tue, 5 Aug 2008 12:53:49 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489833CE.1040801@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> > Just look at sendCommand in this method I have to place a > Thread.sleep(20) after each byte send to get working. Even the event > based receive doesn't work fine but this could be may stupidness. Hi Florian, Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. Regards, Michael Erskine. From florianmanschwetus at gmx.de Tue Aug 5 07:28:15 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:28:15 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> Message-ID: <4898556F.8000208@gmx.de> Michael Erskine schrieb: >> Just look at sendCommand in this method I have to place a >> Thread.sleep(20) after each byte send to get working. Even the event >> based receive doesn't work fine but this could be may stupidness. > > Hi Florian, > > Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. > > Regards, > Michael Erskine. > Ok, sounds fine for the receiving problem. But why i have to wait after each byte when sending a command squence? (the for loop in send command) Florian > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/284f350c/attachment-0020.bin From florianmanschwetus at gmx.de Tue Aug 5 07:44:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:44:14 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <4898592E.2020908@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >>> Just look at sendCommand in this method I have to place a >>> Thread.sleep(20) after each byte send to get working. Even the event >>> based receive doesn't work fine but this could be may stupidness. >> >> Hi Florian, >> >> Yes, naturally you'll have to wait for a response from the other end. >> Why not wait for notification from the event thread perhaps using a >> BlockingDeque rather than your LinkedList. Generally I >> try to decouple all input and output streams: in your case your >> application is operating synchronously like the "expect" program >> (http://expect.nist.gov/) so waits (or timeouts) will need to be >> factored in. >> >> Regards, >> Michael Erskine. >> > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) > > Florian Furthermore there is this basic baud with this confusing javadoc entry: public boolean setBaudBase(int BaudBase) throws UnsupportedCommOperationException, java.io.IOException Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 before using. maybe this could explain something Florian >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/006c7425/attachment-0020.bin From jredman at ergotech.com Tue Aug 5 09:13:36 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 05 Aug 2008 09:13:36 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: Message-ID: <48986E20.3060104@ergotech.com> Trent, So two issues: 1) Technically I'm still not sure how easy/practical a layer would be. The problems are always classes like listeners, and wrapping returns of gnu.io classes. I really see it as a "delegate" type of concept. Any thoughts or ideas of the practicality of this approach? The idea is not to modify RXTX. 2) Javax. The javax namespace does seem to be in widespread use outside of Sun (the same is true for the java namespace). The classpath extensions, or some other location, should be interested in a JavaComm implementation even if it does have dependencies on RXTX. Would you have any philosophical objection to an approach like that? Of course, I suspect it might be better if someone with that authority at Sun would admit that the javax namespace is already in the wild and that there is no problem with it being used within RXTX. Jim Trent Jarvi wrote: > Hi Jim, > > I will not step into the javax.comm namespace without Sun's explicite > permission. I fully understand the pain point you are trying to address. > > In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm > Linux) - which remains an integral part of rxtx. At the time it was a win for > Sun and rxtx. > > The Sun commapi license is/was fairly clear that rxtx should not step into that > namespace. It made sense as Sun was active in that space and rxtx may go into > another namespace - it was an experiment in working with Sun. > > This may sound silly looking at something that happened almost 10 years ago. > In a community of respect which Sun helped create, there is no question about > what to do. I hope eventually Sun will step up and do a right thing too. > > I agree that this is hurting the API more than helping it. There are also > questions about how to replace the API in the long term which includes HID > support which isn't going well so far. > > Others that can't even look at Sun's javax.comm today and can look at Kaffe's > contribution to classpathx can easily work around such restrictions. > > On Mon, 4 Aug 2008, Jim Redman wrote: > >> Has there been any work/would it be possible, to layer a javacomm >> look-alike on top of the GNU code? >> >> The goal is not to move the javax code forward, but to emulate the >> "legacy" javax packages for people who still need this. >> >> Jim >> >> Trent Jarvi wrote: >>> It would be nice to work with Sun to resolve those longstanding issues. >>> But it may not be practical unless the process goes as fast and painless >>> as the grandfathering of commapi did. >>> >>> Another option may be the old kaffe extensions that moved to gnu >>> classpathx. These don't have the native libraries but should provide >>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>> >>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From sandeep at genevasoftech.com Tue Aug 5 11:18:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Tue, 05 Aug 2008 22:48:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <48988B6C.5080409@genevasoftech.com> Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. *-- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/ad20f1cb/attachment-0020.html From Martin.Oberhuber at windriver.com Tue Aug 5 13:30:17 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Tue, 5 Aug 2008 21:30:17 +0200 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Sandeep, shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on Sol7 but I've successfully run it on Sol9 and Sol10. Or is your request really about a native 64bit variant? I'm afraid that then you're out of luck since I think that quite a bit of RXTX is not yet ready for 64 bit. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Sandeep Kumar K Sent: Tuesday, August 05, 2008 7:19 PM To: rxtx at qbang.org Subject: [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so for Solaris 9 Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. -- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/81b7f988/attachment-0020.html From tjarvi at qbang.org Tue Aug 5 22:38:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 22:38:34 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 5 Aug 2008, Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built > on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid that > then > you're out of luck since I think that quite a bit of RXTX is not yet > ready > for 64 bit. > While rxtx-2.1-7 probably has problems, The CVS code should be OK for 64 bit Solaris. If it isn't, let me know and I'll find which patch is missing. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Aug 5 23:13:00 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 23:13:00 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48986E20.3060104@ergotech.com> References: <48986E20.3060104@ergotech.com> Message-ID: On Tue, 5 Aug 2008, Jim Redman wrote: > Trent, > > So two issues: > > 1) Technically I'm still not sure how easy/practical a layer would be. The > problems are always classes like listeners, and wrapping returns of gnu.io > classes. I really see it as a "delegate" type of concept. Any thoughts or > ideas of the practicality of this approach? The idea is not to modify RXTX. I have not put too much thought into this. I assume you want what rxtx 2.0 provided to tie into javax.comm implementations. More classes could be added to rxtx 2.1-7 for SPI support. Maintaining rxtx-2.0 could also be handed to someone if they like. > > 2) Javax. The javax namespace does seem to be in widespread use outside of > Sun (the same is true for the java namespace). The classpath extensions, or > some other location, should be interested in a JavaComm implementation even > if it does have dependencies on RXTX. Would you have any philosophical > objection to an approach like that? > No problems. Classpathx would be a possible place to do it. I'd suggest thinking twice about what this involves in practical terms. You would be wanting to revive the 2.0 API while Sun is at 3.0 and grandfathering the JSR. This undermines the main reason (established api) for using the javax.comm namespace and does not leave such a project in a good position. The only win I see here is maintaining support for applications that can't migrate namespaces. Not that that isn't important. At some point it is going to be less work to just edit the bytecode :) Such a javax.comm effort would also be signing up new projects that decided to use the work up for concerns they probably will not understand or expect. That probably isn't a good path to facilitate for new projects at this time. We will put a good faith effort to work well with others but keep in mind the project has limited bandwidth for such efforts. > Of course, I suspect it might be better if someone with that authority at Sun > would admit that the javax namespace is already in the wild and that there is > no problem with it being used within RXTX. > > Jim > > Trent Jarvi wrote: >> Hi Jim, >> >> I will not step into the javax.comm namespace without Sun's explicite >> permission. I fully understand the pain point you are trying to address. >> >> In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java >> Comm Linux) - which remains an integral part of rxtx. At the time it was a >> win for Sun and rxtx. >> >> The Sun commapi license is/was fairly clear that rxtx should not step into >> that namespace. It made sense as Sun was active in that space and rxtx may >> go into another namespace - it was an experiment in working with Sun. >> >> This may sound silly looking at something that happened almost 10 years >> ago. In a community of respect which Sun helped create, there is no >> question about what to do. I hope eventually Sun will step up and do a >> right thing too. >> >> I agree that this is hurting the API more than helping it. There are also >> questions about how to replace the API in the long term which includes HID >> support which isn't going well so far. >> >> Others that can't even look at Sun's javax.comm today and can look at >> Kaffe's contribution to classpathx can easily work around such >> restrictions. >> >> On Mon, 4 Aug 2008, Jim Redman wrote: >> >>> Has there been any work/would it be possible, to layer a javacomm >>> look-alike on top of the GNU code? >>> >>> The goal is not to move the javax code forward, but to emulate the >>> "legacy" javax packages for people who still need this. >>> >>> Jim >>> >>> Trent Jarvi wrote: >>>> It would be nice to work with Sun to resolve those longstanding issues. >>>> But it may not be practical unless the process goes as fast and painless >>>> as the grandfathering of commapi did. >>>> >>>> Another option may be the old kaffe extensions that moved to gnu >>>> classpathx. These don't have the native libraries but should provide >>>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>>> >>>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From sandeep at genevasoftech.com Wed Aug 6 00:03:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Wed, 06 Aug 2008 11:33:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: <48993EB8.30107@genevasoftech.com> Thank you Mr. Martin for your suggestion. The native file which is given in rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am getting the following error . Any suggestions to solve this issue. I am using Solaris SPARC 64 bit machine. ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) thrown while loading gnu.io.RXTXCommDriver Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(Unknown Source) at java.lang.ClassLoader.loadLibrary(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) at com.ReadFromModem.main(ReadFromModem.java:84) * * *Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid > that then > you're out of luck since I think that quite a bit of RXTX is not yet ready > for 64 bit. > > Cheers, > -- > *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > ------------------------------------------------------------------------ > *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On > Behalf Of *Sandeep Kumar K > *Sent:* Tuesday, August 05, 2008 7:19 PM > *To:* rxtx at qbang.org > *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so > for Solaris 9 > > Hi, > > Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 > bit machine. The librxtxSerial.so given in website is for Solaris 8. > > *-- > > Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/1e920343/attachment-0020.html From tjarvi at qbang.org Wed Aug 6 00:21:42 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 00:21:42 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <48993EB8.30107@genevasoftech.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> <48993EB8.30107@genevasoftech.com> Message-ID: Hi Sandeep You may be out of luck unless you can compile the 2.1 src in CVS (requires gnu make and gcc). But you could try the ToyBox(R)(TM) which is a collection of WiLdLy untested cross compiled 2.1-7 binaries covering everything from the ibm z series to embeded arm/ppc. To give an idea how poorly these are tested, I don't even know if z series machines have a serial port. ftp://www.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Solaris They should at least match the binary types. Actually, I think if you use the rxtx jar from CVS with that file, it should 'work' as the fix for 64 bits was in java not the native code. You could just cd rxtx*/src; javac *.java then jar -cf RXTXcomm.jar `find -name \*.class` to create the hybrid which will complain about version information a bit. On Wed, 6 Aug 2008, Sandeep Kumar K wrote: > Thank you Mr. Martin for your suggestion. The native file which is given in > rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am > getting the following error . > Any suggestions to solve this issue. > I am using Solaris SPARC 64 bit machine. > > ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar > java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 > (Possible cause: architecture word > width mismatch) thrown while loading gnu.io.RXTXCommDriver > Exception in thread "main" java.lang.UnsatisfiedLinkError: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF > class: ELFCLASS64 (Possible cause: > architecture word width mismatch) > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(Unknown Source) > at java.lang.ClassLoader.loadLibrary(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > at com.ReadFromModem.main(ReadFromModem.java:84) > > * > * > > *Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > > > Oberhuber, Martin wrote: >> Sandeep, >> shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse >> variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on >> Sol7 but I've successfully run it on Sol9 and Sol10. >> Or is your request really about a native 64bit variant? I'm afraid that >> then >> you're out of luck since I think that quite a bit of RXTX is not yet ready >> for 64 bit. >> Cheers, >> -- >> *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> ------------------------------------------------------------------------ >> *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On >> Behalf Of *Sandeep Kumar K >> *Sent:* Tuesday, August 05, 2008 7:19 PM >> *To:* rxtx at qbang.org >> *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so >> for Solaris 9 >> >> Hi, >> >> Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 >> bit machine. The librxtxSerial.so given in website is for Solaris 8. >> >> *-- >> Thanks & Regards >> >> Sandeep Kumar K >> Sr. Software Engineer >> Geneva Software Technologies >> Whitefield, Bangalore >> Mob : 9880193454* >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> From michael.erskine at ketech.com Wed Aug 6 01:39:28 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 6 Aug 2008 08:39:28 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Florian Manschwetus wrote: > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) Hi Florian, I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. Regards, Michael Erskine. From florianmanschwetus at gmx.de Wed Aug 6 02:53:16 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 06 Aug 2008 10:53:16 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Message-ID: <4899667C.6010706@gmx.de> Michael Erskine schrieb: > Florian Manschwetus wrote: >> Ok, sounds fine for the receiving problem. >> But why i have to wait after each byte when sending a command squence? >> (the for loop in send command) > > Hi Florian, > I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. > > Regards, > Michael Erskine. > correct with a terminal on the other end it works, my idea was that this basic baud has some influence. Could some one explain what it is for? Florian > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/c2b4fa84/attachment-0020.bin From rick_knight at rlknight.com Wed Aug 6 13:01:07 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:01:07 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F4F3.3020707@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > I have an application (Readerware) that uses RXTX with Javax to access the serial port. This used to work fine under previous Linux' and Java, but something has changed, I assume with Java itself , that is causing the application to fail with a link error. The application is not able to find librxtxSerialParallel.so. RXTX supplies librxtxSerial.so and librxtxParallel.so, but not librxtxSerialParallel.so. Where can I get librxtxSerialParallel.so, or do I need it? Is something else causing the lib to not be found? Thanks, Rick Knight From rick_knight at rlknight.com Wed Aug 6 13:17:55 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:17:55 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F8E3.5060400@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Thanks for the reply. The developer of the app I'm trying to use (Readerware) has sent me a copy of the comm.api and I've copied the library (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar into the proper places. When I try to run the application, I get this error... Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: /usr/lib/libSolarisSerialParallel.so: /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not little-endian (Possible cause: endianness mismatch) Caught java.lang.UnsatisfiedLinkError: com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I while loading driver com.sun.comm.SolarisDriver Is there a way around this error? Thanks again, Rick Knight From jlar310 at gmail.com Wed Aug 6 13:37:42 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 14:37:42 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899F8E3.5060400@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > The developer of the app I'm trying to use (Readerware) has sent me a > copy of the comm.api and I've copied the library > (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar > into the proper places. When I try to run the application, I get this > error... > > Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: > /usr/lib/libSolarisSerialParallel.so: > /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not > little-endian (Possible cause: endianness mismatch) > Caught java.lang.UnsatisfiedLinkError: > com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I > > while loading driver com.sun.comm.SolarisDriver > > Is there a way around this error? What host OS are you running? From your original post it looks like 32 bit Linux. The libSolarisSerialParallel.so file is for Sun Solaris and will vary depending on the underlying hardware architecture as well. Sorry for the double post Rick, but I failed to send this to the list the first time... -- Jeff From rick_knight at rlknight.com Wed Aug 6 13:44:29 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:44:29 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: <4899FF1D.9030504@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > > >> The developer of the app I'm trying to use (Readerware) has sent me a >> copy of the comm.api and I've copied the library >> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >> into the proper places. When I try to run the application, I get this >> error... >> >> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >> /usr/lib/libSolarisSerialParallel.so: >> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >> little-endian (Possible cause: endianness mismatch) >> Caught java.lang.UnsatisfiedLinkError: >> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >> >> while loading driver com.sun.comm.SolarisDriver >> >> Is there a way around this error? >> > > What host OS are you running? From your original post it looks like 32 > bit Linux. > > The libSolarisSerialParallel.so file is for Sun Solaris and will vary > depending on the underlying hardware architecture as well. > > I'm running Kubuntu Linux (debian based). It's 32 bit. Rick Knight From jlar310 at gmail.com Wed Aug 6 15:33:23 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 16:33:23 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > I don't think Sun did binary libraries for Linux in the 2.0 version. Can someone with more historical experience than I confirm that? I recently tried to port a Comm API application from Solaris sparc to Linux x86 and likewise could not get my hands on the binary libraries. I eventually just re-wrote the code to use the gnu namespace packages and rxtx 2.1. What I don't understand is why your application vendor does not provide everything you need to run their software. FYI: I have librxtxParallel.so and librxtxSerial.so installed at JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is /usr/java/default which is actually a softlink to /usr/java/jre1.6.0_05. -- Jeff From defiantlew at yahoo.com.au Wed Aug 6 16:29:33 2008 From: defiantlew at yahoo.com.au (Lew L) Date: Thu, 7 Aug 2008 08:29:33 +1000 Subject: [Rxtx] Sun's Comm API Documentation References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> Message-ID: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> As a matter of interest is the Sun Comm API documentation available somewhere? I have tried the Sun site but it seems to have been removed. Unless I have missed the documentation for RXTX? I javadocced the RXTX source but information (to me) is minimal. Somewhere I got the impression that the Sun Comm API docs is, or was, compatible with RXTX, what is the best docs to use in conjuntion with RXTX and where may the be available? Cheers Lew From rick_knight at rlknight.com Wed Aug 6 17:18:33 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:18:33 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A3149.4050306@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff I'm not sure if I posted this here or not, but when I try to build RXTX from source I get this install error... make all-am make[1]: Entering directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' make[1]: Nothing to be done for `all-am'. make[1]: Leaving directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 Can you tell me how to get past this error and get RXTX built and installed? Thanks, Rick From bboyes at systronix.com Wed Aug 6 17:40:12 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Wed, 06 Aug 2008 17:40:12 -0600 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: At 16:29 08/06/2008, Lew L wrote: >As a matter of interest is the Sun Comm API documentation available >somewhere? I have tried the Sun site but it seems to have been removed. It's in the file we have posted, link in prev email (sorry, in a huge hurry right now). Javadocs definitely there. >Unless I have missed the documentation for RXTX? I javadocced the RXTX >source but information (to me) is minimal. >Somewhere I got the impression that the Sun Comm API docs is, or was, >compatible with RXTX, what is the best docs to use in conjuntion with RXTX >and where may the be available? Yeah, this is one of my concerns/beefs. There is little documentation for RXTX and it isn't just the same as javaxcomm. I would be willing to help out writing docs for RXTX! Yes really... esp if we can fix the Bluetooth issues. best regards Bruce >Cheers >Lew > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx ------- WWW.SYSTRONIX.COM ---------- Real embedded Java and much more +1-801-534-1017 Salt Lake City, USA From rick_knight at rlknight.com Wed Aug 6 17:54:08 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:54:08 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A39A0.2090309@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff, I would like for my vendor to switch to rxtx 2.1. It would make things much easier for me. I'm not sure why he's still using the javax compatible code. He's a small operation. Re-writing the code to use gnu namespace sounds like a major overhaul. Was it? Thanks, Rick From tjarvi at qbang.org Wed Aug 6 21:35:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:35:12 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: >> >>> Jeff wrote: >>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>>> >>>> >>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things > much easier for me. I'm not sure why he's still using the javax > compatible code. He's a small operation. Re-writing the code to use gnu > namespace sounds like a major overhaul. Was it? > Hi Jeff, The changes are fairly mechanical. Imports need to change and any explicite use of the namespace needs to change such as catching an exception. The following script was made for maintaining rxtx 2.0 but can apply to other needs. It is in the contrib dir with rxtx source. #!/bin/sh # Don't use! :) # # Sat, 03 May 2003 16:45:08 Modifications from J?rg Weule # Create a ed-cmd for the change of one pattern # case $1 in gnu) X=g/javax_comm/s+javax_comm+gnu_io+g ;; javax) X=g/gnu_io/s+gnu_io+javax_comm+g ;; *) echo;echo;echo From the top rxtx directory run;echo;echo -e \\t./ChangePackage.sh gnu;echo -e \\t\\tor;echo -e \\t./ChangePackage.sh javax;echo;echo; exit 0 ;; esac # # ed will be used to keep the owner and mode of the files unchanged. # We have run the ed-script for the characters '.' '/' as well. # "tr _ $D" do the change. # find . -type f -a -print | grep -v $0 | (while read F ; do ( echo $X; echo $X| tr _ /; echo $X| tr _ .; echo w; echo q ) | ed $F 2>&1 >/dev/null done ) # # Now we do little changes at the Makefiles. Hope that all we need. # find . -name Makefile\* -a -print | (while read F ; do cat < References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: On Thu, 7 Aug 2008, Lew L wrote: > As a matter of interest is the Sun Comm API documentation available > somewhere? I have tried the Sun site but it seems to have been removed. > > Unless I have missed the documentation for RXTX? I javadocced the RXTX > source but information (to me) is minimal. > Somewhere I got the impression that the Sun Comm API docs is, or was, > compatible with RXTX, what is the best docs to use in conjuntion with RXTX > and where may the be available? > Hi Lew, The documentation on Sun's website is accurate. The changes that are problematic in 3.0 are on the backside which rxtx used to plug into. http://java.sun.com/products/javacomm/reference/api/index.html CommPortIdentifier may have some minor differences (judging by the authors notes). -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Aug 6 21:46:08 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:46:08 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > If javax.comm.properties is properly installed and you are using a 2.0 version of Sun's commapi with rxtx 2.0, you should not see the library attempt to load libSolarisSerialParallel.so. Sun CommAPI 3.0 will not work with any version of rxtx as it is hard coded to use the shared library. See the INSTALL file with rxtx-2.0 source for more help with the properties file. -- Trent Jarvi tjarvi at qbang.org From jlar310 at gmail.com Thu Aug 7 06:32:06 2008 From: jlar310 at gmail.com (Jeff) Date: Thu, 7 Aug 2008 07:32:06 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > Jeff wrote: >> >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >> wrote: >> >>> >>> Jeff wrote: >>> >>>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>> wrote: >>>> >>>> >>>> >>>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things much > easier for me. I'm not sure why he's still using the javax compatible code. > He's a small operation. Re-writing the code to use gnu namespace sounds like > a major overhaul. Was it? I found it quite easy. In fact, in order to accommodate the transition, I actually separated all of the code that deals directly with the Comm API or RXTX into a helper class. The helper class was then coded to use reflection to determine which library was available and then instantiate the necessary objects. No direct imports of either library are used. The main application just needs to get it's hands on the IO streams and need not deal directly with the libraries. Other programs may not be so simple... But this doesn't really help you unless your vendor forks over the source code... -- Jeff From rick_knight at rlknight.com Thu Aug 7 09:47:12 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Thu, 07 Aug 2008 08:47:12 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: <489B1900.10108@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >>> wrote: >>> >>> >>>> Jeff wrote: >>>> >>>> >>>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>>> copy of the comm.api and I've copied the library >>>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>>> into the proper places. When I try to run the application, I get this >>>>>> error... >>>>>> >>>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>>> /usr/lib/libSolarisSerialParallel.so: >>>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>>> little-endian (Possible cause: endianness mismatch) >>>>>> Caught java.lang.UnsatisfiedLinkError: >>>>>> >>>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>>> >>>>>> while loading driver com.sun.comm.SolarisDriver >>>>>> >>>>>> Is there a way around this error? >>>>>> >>>>>> >>>>>> >>>>> What host OS are you running? From your original post it looks like 32 >>>>> bit Linux. >>>>> >>>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>>> depending on the underlying hardware architecture as well. >>>>> >>>>> >>>>> >>>>> >>>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>>> >>>> >>>> >>> I don't think Sun did binary libraries for Linux in the 2.0 version. >>> Can someone with more historical experience than I confirm that? >>> >>> I recently tried to port a Comm API application from Solaris sparc to >>> Linux x86 and likewise could not get my hands on the binary libraries. >>> I eventually just re-wrote the code to use the gnu namespace packages >>> and rxtx 2.1. >>> >>> What I don't understand is why your application vendor does not >>> provide everything you need to run their software. >>> >>> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >>> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >>> /usr/java/default which is actually a softlink to >>> /usr/java/jre1.6.0_05. >>> >>> >>> >> Jeff, >> >> I would like for my vendor to switch to rxtx 2.1. It would make things much >> easier for me. I'm not sure why he's still using the javax compatible code. >> He's a small operation. Re-writing the code to use gnu namespace sounds like >> a major overhaul. Was it? >> > > I found it quite easy. In fact, in order to accommodate the > transition, I actually separated all of the code that deals directly > with the Comm API or RXTX into a helper class. The helper class was > then coded to use reflection to determine which library was available > and then instantiate the necessary objects. No direct imports of > either library are used. The main application just needs to get it's > hands on the IO streams and need not deal directly with the libraries. > Other programs may not be so simple... > > But this doesn't really help you unless your vendor forks over the > source code... > > Jeff, This may not help me directly, but I'm going to forward this thread to the vendor. I think he'll be open to making things work. Thanks again, Rick Knight From agusmunioz at gmail.com Thu Aug 7 16:39:51 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Thu, 7 Aug 2008 19:39:51 -0300 Subject: [Rxtx] How to send ack? Message-ID: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Hi, I'm still learning about serial communication and I have some doubts. I've got this question about how to do the following thing in rxtx. I have this hardware that connect to a PC using a serial port. These hardware receives data from a telephone line, proccess it, and then send it forward to the serial port. I've used a program named wincomm that shows what information is send it through the serial port and I have the nex behaviour: The hardware has a buffer where all data is stored, that cannot be sent it through the seria port. The program reads the first data send it by the hardware, and keep reading the same data always. There is a button in the application that says enable Ack, and when I click, then the hardware start to send all the stored information, and all the information is shown. I write a class, using rxtx that reads the serial port, and the same thing happens, it remains reading the same (first) data all the time. And I thing something like the enable Ack I'm missing. How can I do this enable Ack from my java code using rxtx? Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080807/e0a0f9a1/attachment-0018.html From ajmas at sympatico.ca Thu Aug 7 18:26:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 7 Aug 2008 20:26:41 -0400 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: <4BF42297-81E2-4BB8-A89F-1D43588379AE@sympatico.ca> On 6-Aug-08, at 19:40 , Bruce Boyes wrote: >> Unless I have missed the documentation for RXTX? I javadocced the >> RXTX >> source but information (to me) is minimal. >> Somewhere I got the impression that the Sun Comm API docs is, or was, >> compatible with RXTX, what is the best docs to use in conjuntion >> with RXTX >> and where may the be available? > > Yeah, this is one of my concerns/beefs. There is little documentation > for RXTX and it isn't just the same as javaxcomm. > > I would be willing to help out writing docs for RXTX! Yes really... > esp if we can fix the Bluetooth issues. If you want to contribute documentation then the best place to do that is the wiki. If there is anything missing or that could be improved on then please do so. If there are any points that you would like to see improved, for which you don't have the knowledge then ask on the mailing list for a volunteer. Andre From florianmanschwetus at gmx.de Fri Aug 8 03:04:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Fri, 08 Aug 2008 11:04:14 +0200 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Message-ID: <489C0C0E.2020401@gmx.de> Agustin Mu?oz schrieb: > Hi, I'm still learning about serial communication and I have some > doubts. I've got this question about how to do the following thing in rxtx. > I have this hardware that connect to a PC using a serial port. These > hardware receives data from a telephone line, proccess it, and then send > it forward to the serial port. I've used a program named wincomm that > shows what information is send it through the serial port and I have the > nex behaviour: > > The hardware has a buffer where all data is stored, that cannot be sent > it through the seria port. > The program reads the first data send it by the hardware, and keep > reading the same data always. > There is a button in the application that says enable Ack, and when I > click, then the hardware start to send all the stored information, and > all the information is shown. > > I write a class, using rxtx that reads the serial port, and the same > thing happens, it remains reading the same (first) data all the time. > And I thing something like the enable Ack I'm missing. > How can I do this enable Ack from my java code using rxtx? Afaik, a look at man ascii reveals: Okt Dez Hex Char 006 6 06 ACK So, i hope this will do the job: send(6); florian > > Thanks in advance > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/5b4965f8/attachment-0018.bin From agusmunioz at gmail.com Fri Aug 8 16:31:00 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 19:31:00 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <489C0C0E.2020401@gmx.de> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> Message-ID: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Hi Florian, thanks for the answer. By send(6) you mean to get the port OutputStream and write a 6? I try that but it didn't work. Any suggestion? Thanks On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < florianmanschwetus at gmx.de> wrote: > Agustin Mu?oz schrieb: > > Hi, I'm still learning about serial communication and I have some doubts. >> I've got this question about how to do the following thing in rxtx. >> I have this hardware that connect to a PC using a serial port. These >> hardware receives data from a telephone line, proccess it, and then send it >> forward to the serial port. I've used a program named wincomm that shows >> what information is send it through the serial port and I have the nex >> behaviour: >> >> The hardware has a buffer where all data is stored, that cannot be sent >> it through the seria port. >> The program reads the first data send it by the hardware, and keep reading >> the same data always. >> There is a button in the application that says enable Ack, and when I >> click, then the hardware start to send all the stored information, and all >> the information is shown. >> >> I write a class, using rxtx that reads the serial port, and the same thing >> happens, it remains reading the same (first) data all the time. And I thing >> something like the enable Ack I'm missing. >> How can I do this enable Ack from my java code using rxtx? >> > Afaik, a look at man ascii reveals: > Okt Dez Hex Char > 006 6 06 ACK > So, i hope this will do the job: > send(6); > > florian > >> >> Thanks in advance >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/7f3fba42/attachment-0017.html From agusmunioz at gmail.com Fri Aug 8 18:39:27 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 21:39:27 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Message-ID: <988288430808081739x7f9e7889id82591d5a9e2b4f6@mail.gmail.com> Ok, Florian, it works!! my problem was that I've been sending, through the OutputStream, the bytes of 6 as a string: out.write("6".getBytes()); but then I realized that you can write an int on an OuptuStream, so I tried that and It works: out.write(6); Thank you for the guidance!! On Fri, Aug 8, 2008 at 7:31 PM, Agustin Mu?oz wrote: > Hi Florian, thanks for the answer. By send(6) you mean to get the port > OutputStream and write a 6? > > I try that but it didn't work. > > Any suggestion? > > Thanks > > > On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < > florianmanschwetus at gmx.de> wrote: > >> Agustin Mu?oz schrieb: >> >> Hi, I'm still learning about serial communication and I have some doubts. >>> I've got this question about how to do the following thing in rxtx. >>> I have this hardware that connect to a PC using a serial port. These >>> hardware receives data from a telephone line, proccess it, and then send it >>> forward to the serial port. I've used a program named wincomm that shows >>> what information is send it through the serial port and I have the nex >>> behaviour: >>> >>> The hardware has a buffer where all data is stored, that cannot be sent >>> it through the seria port. >>> The program reads the first data send it by the hardware, and keep >>> reading the same data always. >>> There is a button in the application that says enable Ack, and when I >>> click, then the hardware start to send all the stored information, and all >>> the information is shown. >>> >>> I write a class, using rxtx that reads the serial port, and the same >>> thing happens, it remains reading the same (first) data all the time. And I >>> thing something like the enable Ack I'm missing. >>> How can I do this enable Ack from my java code using rxtx? >>> >> Afaik, a look at man ascii reveals: >> Okt Dez Hex Char >> 006 6 06 ACK >> So, i hope this will do the job: >> send(6); >> >> florian >> >>> >>> Thanks in advance >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/b918ab3d/attachment-0017.html From florianmanschwetus at gmx.de Sat Aug 9 00:45:43 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Sat, 09 Aug 2008 08:45:43 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4899667C.6010706@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> Message-ID: <489D3D17.9090209@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >> Florian Manschwetus wrote: >>> Ok, sounds fine for the receiving problem. >>> But why i have to wait after each byte when sending a command squence? >>> (the for loop in send command) >> >> Hi Florian, >> I'd imagine you probably don't! You could send all bytes in one go and >> RXTX would send them. The problem is most probably the other end: >> perhaps it has a really small buffer, some non-standard UART, or a >> crazy timing issue. If you attach a terminal to your output and send >> all the bytes of a command in one go they should appear no problem. >> >> Regards, >> Michael Erskine. >> > correct with a terminal on the other end it works, my idea was that this > basic baud has some influence. Could some one explain what it is for? > > Florian To make it more clear, my problem is that i can't use: outputStream.write(byte[]); => Beamer doesn't understand the sequence. (mostly no answer when he answers then *001) when i use this construct instead: for (int i = 0; i < command.length; i++) { this.outputStream.write(command[i]); try { Thread.sleep(25); } catch (InterruptedException e) { // TODO Auto-generated catch block e.printStackTrace(); } } it works nearly reliable. So what could it be? This Basic Baud is what exactly? Florian -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080809/692304ee/attachment-0017.bin From tjarvi at qbang.org Sat Aug 9 16:37:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Aug 2008 16:37:19 -0600 (MDT) Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489D3D17.9090209@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> <489D3D17.9090209@gmx.de> Message-ID: On Sat, 9 Aug 2008, Florian Manschwetus wrote: > Florian Manschwetus schrieb: >> Michael Erskine schrieb: >>> Florian Manschwetus wrote: >>>> Ok, sounds fine for the receiving problem. >>>> But why i have to wait after each byte when sending a command squence? >>>> (the for loop in send command) >>> >>> Hi Florian, >>> I'd imagine you probably don't! You could send all bytes in one go and >>> RXTX would send them. The problem is most probably the other end: perhaps >>> it has a really small buffer, some non-standard UART, or a crazy timing >>> issue. If you attach a terminal to your output and send all the bytes of a >>> command in one go they should appear no problem. >>> >>> Regards, >>> Michael Erskine. >>> >> correct with a terminal on the other end it works, my idea was that this >> basic baud has some influence. Could some one explain what it is for? >> >> Florian > To make it more clear, > my problem is that i can't use: > outputStream.write(byte[]); > => Beamer doesn't understand the sequence. (mostly no answer when he answers > then *001) > > when i use this construct instead: > > for (int i = 0; i < command.length; i++) { > this.outputStream.write(command[i]); > try { > Thread.sleep(25); > } catch (InterruptedException e) { > // TODO Auto-generated catch block > e.printStackTrace(); > } > } > > it works nearly reliable. > > So what could it be? This Basic Baud is what exactly? > I suspect you are using the 'moon protocol' and don't know it. RXTX enables this by default. The buffer on the other end is first in first out while reading. If the buffer is full, the bits are hand carried to the moon and burried. Then if the other side reads a couple bytes, two more bytes go into the buffer followed by more moon protocol. The resulting array of bytes the other side reads may appear to be scrambled until you go to the moon, get the bits and insert them in the right place. Flow control can prevent the default moon protocol and throttles the communiation by almost writing a byte at a time as need be. Hardware flow control is preferable but software flow control should also work. Read and write can appear to hang if the other side is not connected. This is why we don't enable them all the time. If you can't use flow control, you have to take care with the moon protocol and give the other side time to read. That is what your slower version of write is doing. -- Trent Jarvi tjarvi at qbang.org From rxtx at allenjb.me.uk Mon Aug 11 08:06:36 2008 From: rxtx at allenjb.me.uk (AllenJB) Date: Mon, 11 Aug 2008 15:06:36 +0100 Subject: [Rxtx] Disabling EV_RXFLAG Message-ID: <48A0476C.2090800@allenjb.me.uk> Hi all, I'm working with a device which does not use an EvtChar and need to disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an event mask of FD 01 00 00. The reference software I have uses FB 00 00 00. With the rxtx mask I get framing errors which I believe are caused when the EvtChar is received. Is there currently a way with rxtx (I've using rxtx from Java) to disable EV_RXFLAG? If not from Java, where would I start if I wanted to turn the EV_RXFLAG option off in the C code? I've had a grep of the rxtx source code, but I can't see where EV_RXFLAG is being set. Thanks in advance, AllenJB From tjarvi at qbang.org Mon Aug 11 14:17:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Aug 2008 14:17:27 -0600 (MDT) Subject: [Rxtx] Disabling EV_RXFLAG In-Reply-To: <48A0476C.2090800@allenjb.me.uk> References: <48A0476C.2090800@allenjb.me.uk> Message-ID: On Mon, 11 Aug 2008, AllenJB wrote: > Hi all, > > I'm working with a device which does not use an EvtChar and need to > disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an > event mask of FD 01 00 00. The reference software I have uses FB 00 00 > 00. With the rxtx mask I get framing errors which I believe are caused > when the EvtChar is received. > > Is there currently a way with rxtx (I've using rxtx from Java) to > disable EV_RXFLAG? > > If not from Java, where would I start if I wanted to turn the EV_RXFLAG > option off in the C code? I've had a grep of the rxtx source code, but I > can't see where EV_RXFLAG is being set. > > Thanks in advance, > > AllenJB Hi Allen, I'd look at termios.c::tcsetattr() and termios.c::FillDCB() -- Trent Jarvi tjarvi at qbang.org From superdadusa at gmail.com Tue Aug 12 13:57:32 2008 From: superdadusa at gmail.com (John Choi) Date: Tue, 12 Aug 2008 13:57:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. Message-ID: Hi all, Just let you all know I just start to learn Java. I have download the serial comm package and the source code from open source communities.. I was able to verify with the given message string via serial monitor. when the given message string sends to the serial port then the character return added to the end of string by default if I use "Hello World" however if I changed to something else other than "Hello, World" there is no character return add to the end of string. I thing the library download from rxtx.org has implemented for the special strings. I can do like "login\n" in the string message to make character return but I don't want to add this individual custom character for each command return in every static message string I send, Can any who have done this might help me? Basically, something like this,, Write and add function to the program write a command, Reads the respond from a serial device.. Function handles multiple messages, Write: "com open" Read: Welcome to my world" expected Write: "admin" Read: Password?, expected Write: "admin" Read: you are successfully login terminal, expected. And I need to add a separate function handler handles a character return add to the each command above. If anyone can help this I can do the reset? Thank you in advance, John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0013.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SerialIO.java Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0013.pl From Steffen.DETTMER at ingenico.com Wed Aug 13 02:16:38 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 13 Aug 2008 10:16:38 +0200 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: References: Message-ID: <20080813081638.GA25412@elberon.bln.de.ingenico.com> * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > I can do like "login\n" in the string message to make character > return but I don't want to add this individual custom character > for each command return in every static message string I send, and why not?! > Can any who have done this might help me? what's about with writing a small wrapper function adding the carriage return? However, this would be slow, because either you call write two times (very bad) or the string needs to be copied, \n appended and written (since you are using Java Performance probably isn't so critical). Personally I would write `"login\n"' and `username + "\n"' etc., because since it is part of the command it should be part of the command definition string. > Basically, something like this,, Write and add function to the program write > a command, Reads the respond from a serial device.. correctly reading a `line' is more difficult. If you cannot make assumptions about timeouts and/or you need to have low delay, you need to read byte wise. If you need to save CPU resources you might need to add some buffering layer that you can read byte-wise but that is reading blockwise with some small timeout (lets say for serial lines something around byte transmission time times three or so). > /* > * To change this template, choose Tools | Templates > * and open the template in the editor. > */ :) > package joliba; > > /** > * > * @author root > */ :) > // derived from SUN's examples in the javax.comm package > import java.io.*; > import java.util.*; > //import javax.comm.*; // for SUN's serial/parallel port libraries > import gnu.io.*; // for rxtxSerial library > > public class SerialIO implements Runnable, SerialPortEventListener { > static CommPortIdentifier portId; > static CommPortIdentifier saveportId; > static Enumeration portList; > InputStream inputStream; > SerialPort serialPort; > Thread readThread; You need a thread for your synchronous RPC-style protocol? > static String messageString = "Hello, world!"; > static OutputStream outputStream; > static boolean outputBufferEmptyFlag = false; > > public static void main(String[] args) { > boolean portFound = false; > String defaultPort; > > // determine the name of the serial port on several operating systems > String osname = System.getProperty("os.name","").toLowerCase(); > if ( osname.startsWith("windows") ) { > // windows > defaultPort = "COM1"; > } else if (osname.startsWith("linux")) { > // linux > defaultPort = "/dev/ttyS0"; > } else if ( osname.startsWith("mac") ) { > // mac > defaultPort = "????"; > } else { > System.out.println("Sorry, your operating system is not supported"); > return; > } Is such a construction recommended? Isn't there some abstraction (like COM1 working on any platform)? [...] > try { > // activate the OUTPUT_BUFFER_EMPTY notifier > serialPort.notifyOnOutputEmpty(true); > } catch (Exception e) { > System.out.println("Error setting event notification"); > System.out.println(e.toString()); > System.exit(-1); > } I doubt that -1 is defined, probably some 127 or so would be the result, maybe better simply `throw e'? > public void writetoport() { > System.out.println("Writing \""+messageString+"\" to "+serialPort.getName()); > try { > // write string to serial port > outputStream.write(messageString.getBytes()); > } catch (IOException e) {} > } maybe something like /** * Writes the given output string and an additional carriage * return to the current outputStream. */ public void writeStringToPort( /** The output string (without CR). */ String output ) throws IOException { String outputLine = output + "\n"; outputStream.write(outputLine.getBytes()); } ? > > public SerialIO() { > // initalize serial port > try { > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > } catch (PortInUseException e) {} if the port is in use, you continue? Wonder that this works in Java, I would assume serialPort beeing uninitialized which AFAIK is an error in Java. > try { > inputStream = serialPort.getInputStream(); > } catch (IOException e) {} > > try { > serialPort.addEventListener(this); > } catch (TooManyListenersException e) {} > > // activate the DATA_AVAILABLE notifier > serialPort.notifyOnDataAvailable(true); > > try { > // set port parameters > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > } catch (UnsupportedCommOperationException e) {} > > // start the read thread > readThread = new Thread(this); > readThread.start(); > > } I think in all those exception cases you can abort, because it is unlikely that ignoring those errors allow a successful continuation, so in this case maybe it would be better to add a throw clause to the method. > public void run() { > // first thing in the thread, we initialize the write operation > initwritetoport(); > try { > while (true) { > // write string to port, the serialEvent will read it > writetoport(); > Thread.sleep(1000); > } > } catch (InterruptedException e) {} > } Does this make sense? Your `SimpleReadApp' writes one and the same string each second? > public void serialEvent(SerialPortEvent event) { > switch (event.getEventType()) { > case SerialPortEvent.BI: > case SerialPortEvent.OE: > case SerialPortEvent.FE: > case SerialPortEvent.PE: > case SerialPortEvent.CD: > case SerialPortEvent.CTS: > case SerialPortEvent.DSR: > case SerialPortEvent.RI: > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > break; > case SerialPortEvent.DATA_AVAILABLE: > // we get here if data has been received > byte[] readBuffer = new byte[20]; > try { > // read data > while (inputStream.available() > 0) { > int numBytes = inputStream.read(readBuffer); > } > // print data > String result = new String(readBuffer); > System.out.println("Read: "+result); > } catch (IOException e) {} I doubt that this is correct. I would assume you will get a 20 bytes result always, if more bytes would be available they would be printed in a second line but if less bytes are read I'd assume that the buffer/result contains zero bytes from implicite readBuffer contents initialisation (zero is no string terminator in Java AFAIK). > break; > } > } > } oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From florianmanschwetus at gmx.de Wed Aug 13 06:09:31 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 13 Aug 2008 14:09:31 +0200 Subject: [Rxtx] someone has seen such errors? Message-ID: <48A2CEFB.90007@gmx.de> I mean my communication mostly works, but it is far from perfect could this be the reason? Florian Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/949b9947/attachment-0013.bin From superdadusa at gmail.com Wed Aug 13 08:40:32 2008 From: superdadusa at gmail.com (John Choi) Date: Wed, 13 Aug 2008 08:40:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: <20080813081638.GA25412@elberon.bln.de.ingenico.com> References: <20080813081638.GA25412@elberon.bln.de.ingenico.com> Message-ID: Thank you so much Steffen and I will try that suggestion. John On 8/13/08, Steffen DETTMER wrote: > > * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > > I can do like "login\n" in the string message to make character > > return but I don't want to add this individual custom character > > for each command return in every static message string I send, > > and why not?! > > > Can any who have done this might help me? > > what's about with writing a small wrapper function adding the > carriage return? > However, this would be slow, because either you call write two > times (very bad) or the string needs to be copied, \n appended > and written (since you are using Java Performance probably isn't > so critical). > > Personally I would write `"login\n"' and `username + "\n"' etc., > because since it is part of the command it should be part of the > command definition string. > > > Basically, something like this,, Write and add function to the program > write > > a command, Reads the respond from a serial device.. > > correctly reading a `line' is more difficult. If you cannot make > assumptions about timeouts and/or you need to have low delay, you > need to read byte wise. If you need to save CPU resources you > might need to add some buffering layer that you can read > byte-wise but that is reading blockwise with some small timeout > (lets say for serial lines something around byte transmission > time times three or so). > > > /* > > * To change this template, choose Tools | Templates > > * and open the template in the editor. > > */ > > :) > > > package joliba; > > > > /** > > * > > * @author root > > */ > > :) > > > // derived from SUN's examples in the javax.comm package > > import java.io.*; > > import java.util.*; > > //import javax.comm.*; // for SUN's serial/parallel port libraries > > import gnu.io.*; // for rxtxSerial library > > > > public class SerialIO implements Runnable, SerialPortEventListener { > > static CommPortIdentifier portId; > > static CommPortIdentifier saveportId; > > static Enumeration portList; > > InputStream inputStream; > > SerialPort serialPort; > > Thread readThread; > > You need a thread for your synchronous RPC-style protocol? > > > static String messageString = "Hello, world!"; > > static OutputStream outputStream; > > static boolean outputBufferEmptyFlag = false; > > > > public static void main(String[] args) { > > boolean portFound = false; > > String defaultPort; > > > > // determine the name of the serial port on several operating > systems > > String osname = System.getProperty("os.name","").toLowerCase(); > > if ( osname.startsWith("windows") ) { > > // windows > > defaultPort = "COM1"; > > } else if (osname.startsWith("linux")) { > > // linux > > defaultPort = "/dev/ttyS0"; > > } else if ( osname.startsWith("mac") ) { > > // mac > > defaultPort = "????"; > > } else { > > System.out.println("Sorry, your operating system is not > supported"); > > return; > > } > > Is such a construction recommended? Isn't there some abstraction > (like COM1 working on any platform)? > > [...] > > try { > > // activate the OUTPUT_BUFFER_EMPTY notifier > > serialPort.notifyOnOutputEmpty(true); > > } catch (Exception e) { > > System.out.println("Error setting event notification"); > > System.out.println(e.toString()); > > System.exit(-1); > > } > > I doubt that -1 is defined, probably some 127 or so would be the > result, maybe better simply `throw e'? > > > public void writetoport() { > > System.out.println("Writing \""+messageString+"\" to > "+serialPort.getName()); > > try { > > // write string to serial port > > outputStream.write(messageString.getBytes()); > > } catch (IOException e) {} > > } > > maybe something like > > /** > * Writes the given output string and an additional carriage > * return to the current outputStream. > */ > public void > writeStringToPort( > /** The output string (without CR). */ > String output > ) throws IOException > { > String outputLine = output + "\n"; > outputStream.write(outputLine.getBytes()); > } > > ? > > > > > public SerialIO() { > > // initalize serial port > > try { > > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > > } catch (PortInUseException e) {} > > if the port is in use, you continue? Wonder that this works in > Java, I would assume serialPort beeing uninitialized which AFAIK > is an error in Java. > > > try { > > inputStream = serialPort.getInputStream(); > > } catch (IOException e) {} > > > > try { > > serialPort.addEventListener(this); > > } catch (TooManyListenersException e) {} > > > > // activate the DATA_AVAILABLE notifier > > serialPort.notifyOnDataAvailable(true); > > > > try { > > // set port parameters > > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > } catch (UnsupportedCommOperationException e) {} > > > > // start the read thread > > readThread = new Thread(this); > > readThread.start(); > > > > } > > I think in all those exception cases you can abort, because it is > unlikely that ignoring those errors allow a successful > continuation, so in this case maybe it would be better to add a > throw clause to the method. > > > public void run() { > > // first thing in the thread, we initialize the write operation > > initwritetoport(); > > try { > > while (true) { > > // write string to port, the serialEvent will read it > > writetoport(); > > Thread.sleep(1000); > > } > > } catch (InterruptedException e) {} > > } > > Does this make sense? Your `SimpleReadApp' writes one and the > same string each second? > > > public void serialEvent(SerialPortEvent event) { > > switch (event.getEventType()) { > > case SerialPortEvent.BI: > > case SerialPortEvent.OE: > > case SerialPortEvent.FE: > > case SerialPortEvent.PE: > > case SerialPortEvent.CD: > > case SerialPortEvent.CTS: > > case SerialPortEvent.DSR: > > case SerialPortEvent.RI: > > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > > break; > > case SerialPortEvent.DATA_AVAILABLE: > > // we get here if data has been received > > byte[] readBuffer = new byte[20]; > > try { > > // read data > > while (inputStream.available() > 0) { > > int numBytes = inputStream.read(readBuffer); > > } > > // print data > > String result = new String(readBuffer); > > System.out.println("Read: "+result); > > } catch (IOException e) {} > > I doubt that this is correct. I would assume you will get a 20 > bytes result always, if more bytes would be available they would > be printed in a second line but if less bytes are read I'd assume > that the buffer/result contains zero bytes from implicite > readBuffer contents initialisation (zero is no string terminator > in Java AFAIK). > > > break; > > } > > } > > } > > oki, > > Steffen > > About Ingenico Throughout the world businesses rely on Ingenico for secure > and expedient electronic transaction acceptance. Ingenico products leverage > proven technology, established standards and unparalleled ergonomics to > provide optimal reliability, versatility and usability. This comprehensive > range of products is complemented by a global array of services and > partnerships, enabling businesses in a number of vertical sectors to accept > transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged > information. If you are not the addressee or authorized to receive this for > the addressee, you must not use, copy, disclose or take any action based on > this message or any information herein. If you have received this message in > error, please advise the sender immediately by reply e-mail and delete this > message. Thank you for your cooperation. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/73c4135c/attachment-0012.html From ajmas at sympatico.ca Sat Aug 16 07:15:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 09:15:41 -0400 Subject: [Rxtx] someone has seen such errors? In-Reply-To: <48A2CEFB.90007@gmx.de> References: <48A2CEFB.90007@gmx.de> Message-ID: <43B5E8DA-1D93-4D90-809B-AAF35FF724C5@sympatico.ca> On 13-Aug-08, at 08:09 , Florian Manschwetus wrote: > I mean my communication mostly works, but it is far from perfect > could this be the reason? > > Florian > > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control Judging by the error messages this looks related to the driver you are using. Do a search for the following string with you favourite search engine, it should turn up a few hits: ftdi_set_termios FAILED to set databits/stopbits/parity Andre From ajmas at sympatico.ca Sat Aug 16 19:12:04 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 21:12:04 -0400 Subject: [Rxtx] Using SerialPortEvent? Message-ID: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Hi, Could someone tell me how I should be using the SerialPortEvent? Am I meant to be waiting for data and then simply reading from the inputstream? If this is the case why no just block on an inputstream read? Andr? From tjarvi at qbang.org Sat Aug 16 19:41:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 16 Aug 2008 19:41:13 -0600 (MDT) Subject: [Rxtx] Using SerialPortEvent? In-Reply-To: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> References: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Message-ID: On Sat, 16 Aug 2008, Andre-John Mas wrote: > Hi, > > Could someone tell me how I should be using the SerialPortEvent? Am I > meant to be waiting for data and then simply reading from the > inputstream? If this is the case why no just block on an inputstream > read? > Polling for data is fine also. It really depends upon what you are trying to do. For instance, if you require x bytes before reading, you can start polling after data is available. If you read on the same thread as your GUI and are waiting for data in a read, the results may be less than desirable. Java programming is 'usually' event driven rather than polling based. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sat Aug 16 20:10:39 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 22:10:39 -0400 Subject: [Rxtx] Using SerialPortEvent? In-Reply-To: References: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Message-ID: <3E495D4C-BB28-4845-A6AB-984C9A826BDF@sympatico.ca> On 16-Aug-08, at 21:41 , Trent Jarvi wrote: > On Sat, 16 Aug 2008, Andre-John Mas wrote: > >> Hi, >> >> Could someone tell me how I should be using the SerialPortEvent? Am I >> meant to be waiting for data and then simply reading from the >> inputstream? If this is the case why no just block on an inputstream >> read? >> > > Polling for data is fine also. It really depends upon what you are > trying to do. For instance, if you require x bytes before reading, > you can start polling after data is available. If you read on the > same thread as your GUI and are waiting for data in a read, the > results may be less than desirable. > > Java programming is 'usually' event driven rather than polling based. Sounds good. I thought I would use this opportunity to provide a event based version of the TwoWaySerialComm example. Could you just validate it before I add it to the Wiki: package ajmas74.experimental; import gnu.io.CommPort; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; import gnu.io.SerialPortEvent; import gnu.io.SerialPortEventListener; import java.io.IOException; import java.io.InputStream; import java.io.OutputStream; /** * This version of the TwoWaySerialComm example makes use of the * SerialPortEventListener to avoid polling. * * @author ajmas * */ public class TwoWaySerialComm { public TwoWaySerialComm() { super(); } void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { CommPort commPort = portIdentifier.open(this.getClass().getName(),2000); if ( commPort instanceof SerialPort ) { SerialPort serialPort = (SerialPort) commPort; serialPort .setSerialPortParams (57600 ,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); (new Thread(new SerialWriter(out))).start(); serialPort.addEventListener(new SerialReader(in)); } else { System.out.println("Error: Only serial ports are handled by this example."); } } } /** * Handles the input coming from the serial port. A new line character * is treated as the end of a block in this example. */ public static class SerialReader implements SerialPortEventListener { private InputStream in; private byte[] buffer = new byte[1024]; public SerialReader ( InputStream in ) { this.in = in; } public void serialEvent(SerialPortEvent arg0) { int data; try { int len = 0; while ( ( data = in.read()) > -1 ) { if ( data != '\n' ) { break; } buffer[len++] = (byte) data; } System.out.print(new String(buffer,0,len)); } catch ( IOException e ) { e.printStackTrace(); System.exit(-1); } } } /** */ public static class SerialWriter implements Runnable { OutputStream out; public SerialWriter ( OutputStream out ) { this.out = out; } public void run () { try { int c = 0; while ( ( c = System.in.read()) > -1 ) { this.out.write(c); } } catch ( IOException e ) { e.printStackTrace(); System.exit(-1); } } } public static void main ( String[] args ) { try { (new TwoWaySerialComm()).connect("COM3"); } catch ( Exception e ) { e.printStackTrace(); } } } From lfarkas at lfarkas.org Tue Aug 19 07:32:59 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Tue, 19 Aug 2008 15:32:59 +0200 Subject: [Rxtx] JNI or CNI Message-ID: <48AACB8B.9060606@lfarkas.org> hi, what is the current recommended way to rxtx on linux JNI or it's better to use CNI? is the CNI version fully functional and the same level as the JNI? i currently try to make a rhel/centos/fedora rpm for rxtx but has many problems with the standard dir structure. yours. -- Levente "Si vis pacem para bellum!" From lfarkas at lfarkas.org Tue Aug 19 08:47:34 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Tue, 19 Aug 2008 16:47:34 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel Message-ID: <48AADD06.7040809@lfarkas.org> hi, newer or not so newer linux kernel do not contain the UTS_RELEASE so the current rxtx is not compile on the latest kernels. even if it's commented out in the cvs configure there are other places. i attcahed a patch which fix it (or at least doesn't cause error at non-debug build). ps. is there any plan to the new 2.1-8 release in the near future? there are many changes (at least the license change in all file and in this case create a diff is very difficult)? the latest release more then 2 years old:-( -- Levente "Si vis pacem para bellum!" -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-2.1-uts.patch Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080819/ab5d38ac/attachment-0006.pl From ajmas at sympatico.ca Tue Aug 19 16:21:53 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 19 Aug 2008 18:21:53 -0400 Subject: [Rxtx] Event based example Message-ID: <24735BFB-B088-4B84-8173-FE98DF63B12F@sympatico.ca> Hi, I have just posted an example of using SerialPortEventListener in the Wiki: http://rxtx.qbang.org/wiki/index.php/Event_Based_Two_Way_Communication If you see any issues please could you let me know, or makes the changes. Andre From Martin.Oberhuber at windriver.com Fri Aug 22 04:02:24 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 22 Aug 2008 12:02:24 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <48AADD06.7040809@lfarkas.org> References: <48AADD06.7040809@lfarkas.org> Message-ID: <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> Farkas, there are indeed efforts to get a new RXTX release out the door. Your experience as a package maintainer would likely be helpful during these efforts, since I'd think it makes sense to keep the patches minimal that you must make to have the source compile in your environment. What are the things that you find problematic, apart from the UTS thing that you have mentioned before? What is the timing that you have in mind for your package? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Farkas Levente > Sent: Tuesday, August 19, 2008 4:48 PM > To: rxtx at qbang.org > Subject: [Rxtx] UTS_RELEASE not defined in newer kernel > > hi, > newer or not so newer linux kernel do not contain the > UTS_RELEASE so the > current rxtx is not compile on the latest kernels. even if it's > commented out in the cvs configure there are other places. > i attcahed a patch which fix it (or at least doesn't cause error at > non-debug build). > > ps. is there any plan to the new 2.1-8 release in the near > future? there > are many changes (at least the license change in all file and in this > case create a diff is very difficult)? the latest release more then 2 > years old:-( > > -- > Levente "Si vis pacem para bellum!" > From lfarkas at lfarkas.org Fri Aug 22 04:36:26 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Fri, 22 Aug 2008 12:36:26 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> References: <48AADD06.7040809@lfarkas.org> <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> Message-ID: <48AE96AA.6090505@lfarkas.org> hi, the packages already build for fedora-9 and centos-5 and here: http://www.lfarkas.org/linux/packages/ what i've to patch, the UTS, the configure script, but it's already fixed in the cvs (in another way) and the loadlibrary. the reasons for last one can be found here: https://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_files_that_use_JNI after we test it i'd like to add these packages to fedora and epel main repository (that's why it's be useful a new release after 2 years:-) imho versions are cheap and why not just release 2.1-8? the real code changes are minimal and if something critical bug found still can release 2.1-9:-) ps. and would be better to use simple number for version like 2.1-7 rather then 2.1-7v2. Oberhuber, Martin wrote: > Farkas, > > there are indeed efforts to get a new RXTX release out the > door. Your experience as a package maintainer would likely > be helpful during these efforts, since I'd think it makes > sense to keep the patches minimal that you must make to > have the source compile in your environment. > > What are the things that you find problematic, apart from > the UTS thing that you have mentioned before? > > What is the timing that you have in mind for your package? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >> On Behalf Of Farkas Levente >> Sent: Tuesday, August 19, 2008 4:48 PM >> To: rxtx at qbang.org >> Subject: [Rxtx] UTS_RELEASE not defined in newer kernel >> >> hi, >> newer or not so newer linux kernel do not contain the >> UTS_RELEASE so the >> current rxtx is not compile on the latest kernels. even if it's >> commented out in the cvs configure there are other places. >> i attcahed a patch which fix it (or at least doesn't cause error at >> non-debug build). >> >> ps. is there any plan to the new 2.1-8 release in the near >> future? there >> are many changes (at least the license change in all file and in this >> case create a diff is very difficult)? the latest release more then 2 >> years old:-( >> >> -- >> Levente "Si vis pacem para bellum!" >> -- Levente "Si vis pacem para bellum!" From tjarvi at qbang.org Fri Aug 22 18:50:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Aug 2008 18:50:32 -0600 (MDT) Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <48AE96AA.6090505@lfarkas.org> References: <48AADD06.7040809@lfarkas.org> <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> <48AE96AA.6090505@lfarkas.org> Message-ID: Hi Farkas, The v2 was simply the second build - no code changes. We are comming out with a new release shortly. I would encourage working with distros as you are. The building of rxtx turns out to be a bottle neck in quick releases. We do want stable releases that work for a year or more but I would have no problems with quicker cycles on developing work. I would have no problem working with someone that did builds that receive less testing more often but they do have to come out for multiple platforms from this end. Thanks for the links. On Fri, 22 Aug 2008, Farkas Levente wrote: > hi, > the packages already build for fedora-9 and centos-5 and here: > http://www.lfarkas.org/linux/packages/ > what i've to patch, the UTS, the configure script, but it's already > fixed in the cvs (in another way) and the loadlibrary. the reasons for > last one can be found here: > https://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_files_that_use_JNI > after we test it i'd like to add these packages to fedora and epel main > repository (that's why it's be useful a new release after 2 years:-) > imho versions are cheap and why not just release 2.1-8? the real code > changes are minimal and if something critical bug found still can > release 2.1-9:-) > > ps. and would be better to use simple number for version like 2.1-7 > rather then 2.1-7v2. > > Oberhuber, Martin wrote: >> Farkas, >> >> there are indeed efforts to get a new RXTX release out the >> door. Your experience as a package maintainer would likely >> be helpful during these efforts, since I'd think it makes >> sense to keep the patches minimal that you must make to >> have the source compile in your environment. >> >> What are the things that you find problematic, apart from >> the UTS thing that you have mentioned before? >> >> What is the timing that you have in mind for your package? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >>> On Behalf Of Farkas Levente >>> Sent: Tuesday, August 19, 2008 4:48 PM >>> To: rxtx at qbang.org >>> Subject: [Rxtx] UTS_RELEASE not defined in newer kernel >>> >>> hi, >>> newer or not so newer linux kernel do not contain the >>> UTS_RELEASE so the >>> current rxtx is not compile on the latest kernels. even if it's >>> commented out in the cvs configure there are other places. >>> i attcahed a patch which fix it (or at least doesn't cause error at >>> non-debug build). >>> >>> ps. is there any plan to the new 2.1-8 release in the near >>> future? there >>> are many changes (at least the license change in all file and in this >>> case create a diff is very difficult)? the latest release more then 2 >>> years old:-( >>> >>> -- >>> Levente "Si vis pacem para bellum!" >>> > > > From andy at triera.net Sat Aug 23 15:17:44 2008 From: andy at triera.net (Andy Rozman) Date: Sat, 23 Aug 2008 21:17:44 +0000 Subject: [Rxtx] port not identified on FreeBSD In-Reply-To: References: Message-ID: <48B07E78.2030306@triera.net> Hi ! I have one small problem... I have started using FreeBSD in last few days and I have come accross a problem with rxtx on FreeBSD. I am using usb-to-serial converter, which is identified under FreeBSD without problem as ucom0, and creates link under /dev called ttyU0, which is correct way to be done under FreeBSD (if device would be unidentified it would be called ugen0 - as usb generic). Problem is that I say to rxtx to get my all serial ports this one is not among them. Which names are permissable under linux-like implementations? Which will be accepted as serial ports? Andy From tjarvi at qbang.org Sat Aug 23 13:57:45 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 23 Aug 2008 13:57:45 -0600 (MDT) Subject: [Rxtx] port not identified on FreeBSD In-Reply-To: <48B07E78.2030306@triera.net> References: <48B07E78.2030306@triera.net> Message-ID: On Sat, 23 Aug 2008, Andy Rozman wrote: > Hi ! > > I have one small problem... I have started using FreeBSD in last few > days and I have come accross a problem with rxtx on FreeBSD. > > I am using usb-to-serial converter, which is identified under FreeBSD > without problem as ucom0, and creates link under /dev called > ttyU0, which is correct way to be done under FreeBSD (if device would be > unidentified it would be called ugen0 - as usb generic). Problem is that > I say to rxtx to get my all serial ports this one is not among them. > Which names are permissable under linux-like implementations? Which will > be accepted as serial ports? > > Andy > Thanks Andy! We will add ttyU* to FreeBSD. For now you can use properties to enable the port. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting#How_does_rxtx_detect_ports.3F__Can_I_override_it.3F The fix: diff -u -r1.16.2.59 RXTXCommDriver.java --- RXTXCommDriver.java 18 Nov 2007 22:32:41 -0000 1.16.2.59 +++ RXTXCommDriver.java 23 Aug 2008 19:55:25 -0000 @@ -644,6 +644,7 @@ { String[] Temp = { "ttyd", //general purpose serial ports + "ttyU", //general purpose USB serial ports "cuaa", //dialout serial ports "ttyA", //Specialix SI/XIO dialin ports "cuaA", //Specialix SI/XIO dialout ports -- Trent Jarvi tjarvi at qbang.org From rick_knight at rlknight.com Mon Aug 4 13:25:10 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Mon, 04 Aug 2008 12:25:10 -0700 Subject: [Rxtx] Sun's Comm API? Message-ID: <48975796.4010600@rlknight.com> I have an application that requires the javax compatible version of RXTX and Sun's comm api. I've been able to download and extract the version of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api anywhere. Can someone tell me where I can find it? Or maybe send me a copy? Also, when I try to build RXTX, configure and make complete successfully but make install failes with this error libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 I've never come accross this error before. How can I get past it? Thanks, Rick From bboyes at systronix.com Mon Aug 4 19:10:01 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:10:01 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48975796.4010600@rlknight.com> References: <48975796.4010600@rlknight.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/cb9c6167/attachment-0022.html From bboyes at systronix.com Mon Aug 4 19:12:37 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:12:37 -0600 Subject: [Rxtx] Towards an RXTX release - CSR BT/USB chipset In-Reply-To: <488FB7E7.8000802@gmail.com> References: <460801A4097E3D4CA04CC64EE648584806C56CF0@ism-mail03.corp.ad.wrs.com> <13557-75390@sneakemail.com> <20980-23424@sneakemail.com> <488FB7E7.8000802@gmail.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/52236088/attachment-0022.html From tjarvi at qbang.org Mon Aug 4 19:42:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 19:42:21 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: On Mon, 4 Aug 2008, Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: > I have an application that requires the javax compatible > version of RXTX > and Sun's comm api. I've been able to download and extract > the version > of RXTX that I need (2.0-7pre2) but I can't find Sun's camm > api > anywhere. Can someone tell me where I can find it? Or maybe > send me a > > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm port > support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have just > a ZIP with only the .class JAR file - no source or docs), has a readme > with these comments: > > This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release.? The 2.0.3 release itself is > no longer distributed.? comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project.? The RxTx project (http://www.rxtx.org ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org) was opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support.? Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins.? Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > ? > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > I hope that is helpful! > It would be nice to work with Sun to resolve those longstanding issues. But it may not be practical unless the process goes as fast and painless as the grandfathering of commapi did. Another option may be the old kaffe extensions that moved to gnu classpathx. These don't have the native libraries but should provide the 2.0 interface and the javax.comm.properties mechansim for SPI. http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Mon Aug 4 20:23:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Mon, 04 Aug 2008 20:23:57 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4897B9BD.5070809@ergotech.com> Has there been any work/would it be possible, to layer a javacomm look-alike on top of the GNU code? The goal is not to move the javax code forward, but to emulate the "legacy" javax packages for people who still need this. Jim Trent Jarvi wrote: > On Mon, 4 Aug 2008, Bruce Boyes wrote: > >> At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible >> version of RXTX >> and Sun's comm api. I've been able to download and extract >> the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm >> api >> anywhere. Can someone tell me where I can find it? Or maybe >> send me a >> >> >> javaxcomm has had a sort of on-again off-again history. The windoze >> version has been languishing for years (literally) but there are newer >> versions for other OS's. >> >> We try to keep links on one of our help pages current: >> http://www.practicalembeddedjava.com/tools/javatools_list.html >> which gets you to here: >> http://java.sun.com/products/javacomm/ >> where it says in fact they no longer even support Windows and Mac: >> "Implementations of the API are currently available for Solaris SPARC, >> Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so >> someone could support it. But I guess that's part of the reason RXTX >> exists! >> >> So one of Sun's own products, SunSPOT, has to use RXTX to get comm port >> support. >> >> The version we use is 2.0 from 11/15/1998. I have posted it on our >> website, which is within the terms of the license agreement contained >> therein (as I understand it). >> >> The last version of javaxcomm for Windows, 2.0.3, (for which I have just >> a ZIP with only the .class JAR file - no source or docs), has a readme >> with these comments: >> >> This distribution contains the comm.jar file original part >> of the COMMAPI 2.0.3 release. The 2.0.3 release itself is >> no longer distributed. comm.jar, which contains the comm >> API java class files (eg. Sun's binary implementation of the >> interface classes), is being made available, unsupported, >> with no obligation to fix bugs, at the request of the RXTX >> project. The RxTx project (http://www.rxtx.org ), uses the >> comm.jar class files, but provides their own native library >> components to provide support for other platforms. >> >> The 2.0.3 comm.jar is being provided in this way because >> as of COMMAPI 3.x, the java binary implementation forked and >> became incompatible with the RxTx project's native code. >> Due to the lack of a clear business case, and to resource >> constraints, no additional resources are being >> provided to provide an alternative engineering solution >> at the time of writing. >> >> RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: >> >> Ultimately the COMMAPI would be better served if a Java >> Community Process JSR (http://www.jcp.org) was opened and >> the COMMAPI was rearchitected to provide a more pluggable >> framework to improve cross-platform support. Such an >> architecture would embody a better defined and better >> documented SPI interface, including a way for comm. ports >> to be revealed to the client application through the API >> via platform-aware plugins. Similarly, native code used >> to access comm port in general could be handled more >> flexibly using a plugin model, whereby on any platform, >> multiple native modules could be in use simultaneously. >> >> Since there are now various ways serial ports can be implemented >> and accessed, modular comm. port JNI native libraries would be >> of benefit insofar as removing the burden of over-generalization >> from any single native component, or inversely, by relieving the >> implicit constraint that comm. drivers be accessed only via a >> monolithic mechanism, such as the UNIX vnode interface. >> >> paul.klissner at sun.com >> 6/10/06 >> >> I hope that is helpful! >> > > It would be nice to work with Sun to resolve those longstanding issues. > But it may not be practical unless the process goes as fast and painless > as the grandfathering of commapi did. > > Another option may be the old kaffe extensions that moved to gnu > classpathx. These don't have the native libraries but should provide > the 2.0 interface and the javax.comm.properties mechansim for SPI. > > http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Mon Aug 4 21:09:15 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 21:09:15 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? Message-ID: Hi Jim, I will not step into the javax.comm namespace without Sun's explicite permission. I fully understand the pain point you are trying to address. In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm Linux) - which remains an integral part of rxtx. At the time it was a win for Sun and rxtx. The Sun commapi license is/was fairly clear that rxtx should not step into that namespace. It made sense as Sun was active in that space and rxtx may go into another namespace - it was an experiment in working with Sun. This may sound silly looking at something that happened almost 10 years ago. In a community of respect which Sun helped create, there is no question about what to do. I hope eventually Sun will step up and do a right thing too. I agree that this is hurting the API more than helping it. There are also questions about how to replace the API in the long term which includes HID support which isn't going well so far. Others that can't even look at Sun's javax.comm today and can look at Kaffe's contribution to classpathx can easily work around such restrictions. On Mon, 4 Aug 2008, Jim Redman wrote: > Has there been any work/would it be possible, to layer a javacomm > look-alike on top of the GNU code? > > The goal is not to move the javax code forward, but to emulate the > "legacy" javax packages for people who still need this. > > Jim > > Trent Jarvi wrote: >> >> It would be nice to work with Sun to resolve those longstanding issues. >> But it may not be practical unless the process goes as fast and painless >> as the grandfathering of commapi did. >> >> Another option may be the old kaffe extensions that moved to gnu >> classpathx. These don't have the native libraries but should provide >> the 2.0 interface and the javax.comm.properties mechansim for SPI. >> >> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From florianmanschwetus at gmx.de Tue Aug 5 05:04:46 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 13:04:46 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: References: <48971C1F.9020806@gmx.de> Message-ID: <489833CE.1040801@gmx.de> Just look at sendCommand in this method I have to place a Thread.sleep(20) after each byte send to get working. Even the event based receive doesn't work fine but this could be may stupidness. The specifikation document (it is on the last pages of the manual) for the beamer could be found on: http://www.optoma.co.uk/support.aspx Florian Manschwetus Trent Jarvi schrieb: > > Hi Florian > > Sorry for the top post in advance. I worry you may not see my answer > under all your code :) > > I have not received this email before. This is 500k of code which I > don't have time to read. I can spend about 5 min on each hobby email > and still get to work in the morning. I have a couple suggestions for > how to get an answer. > > First, cut out your comments and extra code so you can demonstrate the > question (I might even glance and see what is wrong then). Don't go for > a working final product. Isolate the problem using a simple program and > then ask with that as an example. If I did what you just did, I'd have > to post 3/4 of a million lines of code :) > > Second, join the rxtx mail-list and ask there. This will give you 100x > more eyes. I'll also read and try to follow. > > -- > taj > > > > On Mon, 4 Aug 2008, Florian Manschwetus wrote: > >> It could be that my university account is blocked by filters so >> resending from here. >> >> >> Topic is to control Optoma HD80 beamer using rs232 serial chat. >> This code is able to detect power state and switch the beamer on / off. >> connected is the beamer using a digitus usb 2.0 serial adapter with an >> FT232 USB-Serial adapter the systems architecture is amd64. >> >> Please take a look in the sendCommand routine i have to place theire >> those Thread.sleep to get it working. >> Now the question is this correct or is there a better way to get this >> working correctly? >> >> In the javadoc coming with the install i found this: >> setBaudBase >> >> public boolean setBaudBase(int BaudBase) >> throws UnsupportedCommOperationException, >> java.io.IOException >> >> Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 >> before using. >> >> could this explain the error? >> I attached my java source and the protocol description for the beamer >> (available on vendor website). >> >> thx, >> Florian Manschwetus >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: TestRS232.java Type: text/x-java Size: 9143 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0044.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0045.bin From michael.erskine at ketech.com Tue Aug 5 05:53:49 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Tue, 5 Aug 2008 12:53:49 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489833CE.1040801@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> > Just look at sendCommand in this method I have to place a > Thread.sleep(20) after each byte send to get working. Even the event > based receive doesn't work fine but this could be may stupidness. Hi Florian, Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. Regards, Michael Erskine. From florianmanschwetus at gmx.de Tue Aug 5 07:28:15 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:28:15 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> Message-ID: <4898556F.8000208@gmx.de> Michael Erskine schrieb: >> Just look at sendCommand in this method I have to place a >> Thread.sleep(20) after each byte send to get working. Even the event >> based receive doesn't work fine but this could be may stupidness. > > Hi Florian, > > Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. > > Regards, > Michael Erskine. > Ok, sounds fine for the receiving problem. But why i have to wait after each byte when sending a command squence? (the for loop in send command) Florian > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/284f350c/attachment-0021.bin From florianmanschwetus at gmx.de Tue Aug 5 07:44:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:44:14 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <4898592E.2020908@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >>> Just look at sendCommand in this method I have to place a >>> Thread.sleep(20) after each byte send to get working. Even the event >>> based receive doesn't work fine but this could be may stupidness. >> >> Hi Florian, >> >> Yes, naturally you'll have to wait for a response from the other end. >> Why not wait for notification from the event thread perhaps using a >> BlockingDeque rather than your LinkedList. Generally I >> try to decouple all input and output streams: in your case your >> application is operating synchronously like the "expect" program >> (http://expect.nist.gov/) so waits (or timeouts) will need to be >> factored in. >> >> Regards, >> Michael Erskine. >> > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) > > Florian Furthermore there is this basic baud with this confusing javadoc entry: public boolean setBaudBase(int BaudBase) throws UnsupportedCommOperationException, java.io.IOException Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 before using. maybe this could explain something Florian >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/006c7425/attachment-0021.bin From jredman at ergotech.com Tue Aug 5 09:13:36 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 05 Aug 2008 09:13:36 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: Message-ID: <48986E20.3060104@ergotech.com> Trent, So two issues: 1) Technically I'm still not sure how easy/practical a layer would be. The problems are always classes like listeners, and wrapping returns of gnu.io classes. I really see it as a "delegate" type of concept. Any thoughts or ideas of the practicality of this approach? The idea is not to modify RXTX. 2) Javax. The javax namespace does seem to be in widespread use outside of Sun (the same is true for the java namespace). The classpath extensions, or some other location, should be interested in a JavaComm implementation even if it does have dependencies on RXTX. Would you have any philosophical objection to an approach like that? Of course, I suspect it might be better if someone with that authority at Sun would admit that the javax namespace is already in the wild and that there is no problem with it being used within RXTX. Jim Trent Jarvi wrote: > Hi Jim, > > I will not step into the javax.comm namespace without Sun's explicite > permission. I fully understand the pain point you are trying to address. > > In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm > Linux) - which remains an integral part of rxtx. At the time it was a win for > Sun and rxtx. > > The Sun commapi license is/was fairly clear that rxtx should not step into that > namespace. It made sense as Sun was active in that space and rxtx may go into > another namespace - it was an experiment in working with Sun. > > This may sound silly looking at something that happened almost 10 years ago. > In a community of respect which Sun helped create, there is no question about > what to do. I hope eventually Sun will step up and do a right thing too. > > I agree that this is hurting the API more than helping it. There are also > questions about how to replace the API in the long term which includes HID > support which isn't going well so far. > > Others that can't even look at Sun's javax.comm today and can look at Kaffe's > contribution to classpathx can easily work around such restrictions. > > On Mon, 4 Aug 2008, Jim Redman wrote: > >> Has there been any work/would it be possible, to layer a javacomm >> look-alike on top of the GNU code? >> >> The goal is not to move the javax code forward, but to emulate the >> "legacy" javax packages for people who still need this. >> >> Jim >> >> Trent Jarvi wrote: >>> It would be nice to work with Sun to resolve those longstanding issues. >>> But it may not be practical unless the process goes as fast and painless >>> as the grandfathering of commapi did. >>> >>> Another option may be the old kaffe extensions that moved to gnu >>> classpathx. These don't have the native libraries but should provide >>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>> >>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From sandeep at genevasoftech.com Tue Aug 5 11:18:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Tue, 05 Aug 2008 22:48:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <48988B6C.5080409@genevasoftech.com> Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. *-- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/ad20f1cb/attachment-0021.html From Martin.Oberhuber at windriver.com Tue Aug 5 13:30:17 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Tue, 5 Aug 2008 21:30:17 +0200 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Sandeep, shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on Sol7 but I've successfully run it on Sol9 and Sol10. Or is your request really about a native 64bit variant? I'm afraid that then you're out of luck since I think that quite a bit of RXTX is not yet ready for 64 bit. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Sandeep Kumar K Sent: Tuesday, August 05, 2008 7:19 PM To: rxtx at qbang.org Subject: [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so for Solaris 9 Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. -- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/81b7f988/attachment-0021.html From tjarvi at qbang.org Tue Aug 5 22:38:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 22:38:34 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 5 Aug 2008, Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built > on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid that > then > you're out of luck since I think that quite a bit of RXTX is not yet > ready > for 64 bit. > While rxtx-2.1-7 probably has problems, The CVS code should be OK for 64 bit Solaris. If it isn't, let me know and I'll find which patch is missing. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Aug 5 23:13:00 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 23:13:00 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48986E20.3060104@ergotech.com> References: <48986E20.3060104@ergotech.com> Message-ID: On Tue, 5 Aug 2008, Jim Redman wrote: > Trent, > > So two issues: > > 1) Technically I'm still not sure how easy/practical a layer would be. The > problems are always classes like listeners, and wrapping returns of gnu.io > classes. I really see it as a "delegate" type of concept. Any thoughts or > ideas of the practicality of this approach? The idea is not to modify RXTX. I have not put too much thought into this. I assume you want what rxtx 2.0 provided to tie into javax.comm implementations. More classes could be added to rxtx 2.1-7 for SPI support. Maintaining rxtx-2.0 could also be handed to someone if they like. > > 2) Javax. The javax namespace does seem to be in widespread use outside of > Sun (the same is true for the java namespace). The classpath extensions, or > some other location, should be interested in a JavaComm implementation even > if it does have dependencies on RXTX. Would you have any philosophical > objection to an approach like that? > No problems. Classpathx would be a possible place to do it. I'd suggest thinking twice about what this involves in practical terms. You would be wanting to revive the 2.0 API while Sun is at 3.0 and grandfathering the JSR. This undermines the main reason (established api) for using the javax.comm namespace and does not leave such a project in a good position. The only win I see here is maintaining support for applications that can't migrate namespaces. Not that that isn't important. At some point it is going to be less work to just edit the bytecode :) Such a javax.comm effort would also be signing up new projects that decided to use the work up for concerns they probably will not understand or expect. That probably isn't a good path to facilitate for new projects at this time. We will put a good faith effort to work well with others but keep in mind the project has limited bandwidth for such efforts. > Of course, I suspect it might be better if someone with that authority at Sun > would admit that the javax namespace is already in the wild and that there is > no problem with it being used within RXTX. > > Jim > > Trent Jarvi wrote: >> Hi Jim, >> >> I will not step into the javax.comm namespace without Sun's explicite >> permission. I fully understand the pain point you are trying to address. >> >> In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java >> Comm Linux) - which remains an integral part of rxtx. At the time it was a >> win for Sun and rxtx. >> >> The Sun commapi license is/was fairly clear that rxtx should not step into >> that namespace. It made sense as Sun was active in that space and rxtx may >> go into another namespace - it was an experiment in working with Sun. >> >> This may sound silly looking at something that happened almost 10 years >> ago. In a community of respect which Sun helped create, there is no >> question about what to do. I hope eventually Sun will step up and do a >> right thing too. >> >> I agree that this is hurting the API more than helping it. There are also >> questions about how to replace the API in the long term which includes HID >> support which isn't going well so far. >> >> Others that can't even look at Sun's javax.comm today and can look at >> Kaffe's contribution to classpathx can easily work around such >> restrictions. >> >> On Mon, 4 Aug 2008, Jim Redman wrote: >> >>> Has there been any work/would it be possible, to layer a javacomm >>> look-alike on top of the GNU code? >>> >>> The goal is not to move the javax code forward, but to emulate the >>> "legacy" javax packages for people who still need this. >>> >>> Jim >>> >>> Trent Jarvi wrote: >>>> It would be nice to work with Sun to resolve those longstanding issues. >>>> But it may not be practical unless the process goes as fast and painless >>>> as the grandfathering of commapi did. >>>> >>>> Another option may be the old kaffe extensions that moved to gnu >>>> classpathx. These don't have the native libraries but should provide >>>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>>> >>>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From sandeep at genevasoftech.com Wed Aug 6 00:03:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Wed, 06 Aug 2008 11:33:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: <48993EB8.30107@genevasoftech.com> Thank you Mr. Martin for your suggestion. The native file which is given in rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am getting the following error . Any suggestions to solve this issue. I am using Solaris SPARC 64 bit machine. ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) thrown while loading gnu.io.RXTXCommDriver Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(Unknown Source) at java.lang.ClassLoader.loadLibrary(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) at com.ReadFromModem.main(ReadFromModem.java:84) * * *Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid > that then > you're out of luck since I think that quite a bit of RXTX is not yet ready > for 64 bit. > > Cheers, > -- > *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > ------------------------------------------------------------------------ > *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On > Behalf Of *Sandeep Kumar K > *Sent:* Tuesday, August 05, 2008 7:19 PM > *To:* rxtx at qbang.org > *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so > for Solaris 9 > > Hi, > > Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 > bit machine. The librxtxSerial.so given in website is for Solaris 8. > > *-- > > Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/1e920343/attachment-0021.html From tjarvi at qbang.org Wed Aug 6 00:21:42 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 00:21:42 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <48993EB8.30107@genevasoftech.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> <48993EB8.30107@genevasoftech.com> Message-ID: Hi Sandeep You may be out of luck unless you can compile the 2.1 src in CVS (requires gnu make and gcc). But you could try the ToyBox(R)(TM) which is a collection of WiLdLy untested cross compiled 2.1-7 binaries covering everything from the ibm z series to embeded arm/ppc. To give an idea how poorly these are tested, I don't even know if z series machines have a serial port. ftp://www.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Solaris They should at least match the binary types. Actually, I think if you use the rxtx jar from CVS with that file, it should 'work' as the fix for 64 bits was in java not the native code. You could just cd rxtx*/src; javac *.java then jar -cf RXTXcomm.jar `find -name \*.class` to create the hybrid which will complain about version information a bit. On Wed, 6 Aug 2008, Sandeep Kumar K wrote: > Thank you Mr. Martin for your suggestion. The native file which is given in > rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am > getting the following error . > Any suggestions to solve this issue. > I am using Solaris SPARC 64 bit machine. > > ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar > java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 > (Possible cause: architecture word > width mismatch) thrown while loading gnu.io.RXTXCommDriver > Exception in thread "main" java.lang.UnsatisfiedLinkError: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF > class: ELFCLASS64 (Possible cause: > architecture word width mismatch) > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(Unknown Source) > at java.lang.ClassLoader.loadLibrary(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > at com.ReadFromModem.main(ReadFromModem.java:84) > > * > * > > *Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > > > Oberhuber, Martin wrote: >> Sandeep, >> shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse >> variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on >> Sol7 but I've successfully run it on Sol9 and Sol10. >> Or is your request really about a native 64bit variant? I'm afraid that >> then >> you're out of luck since I think that quite a bit of RXTX is not yet ready >> for 64 bit. >> Cheers, >> -- >> *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> ------------------------------------------------------------------------ >> *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On >> Behalf Of *Sandeep Kumar K >> *Sent:* Tuesday, August 05, 2008 7:19 PM >> *To:* rxtx at qbang.org >> *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so >> for Solaris 9 >> >> Hi, >> >> Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 >> bit machine. The librxtxSerial.so given in website is for Solaris 8. >> >> *-- >> Thanks & Regards >> >> Sandeep Kumar K >> Sr. Software Engineer >> Geneva Software Technologies >> Whitefield, Bangalore >> Mob : 9880193454* >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> From michael.erskine at ketech.com Wed Aug 6 01:39:28 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 6 Aug 2008 08:39:28 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Florian Manschwetus wrote: > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) Hi Florian, I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. Regards, Michael Erskine. From florianmanschwetus at gmx.de Wed Aug 6 02:53:16 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 06 Aug 2008 10:53:16 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Message-ID: <4899667C.6010706@gmx.de> Michael Erskine schrieb: > Florian Manschwetus wrote: >> Ok, sounds fine for the receiving problem. >> But why i have to wait after each byte when sending a command squence? >> (the for loop in send command) > > Hi Florian, > I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. > > Regards, > Michael Erskine. > correct with a terminal on the other end it works, my idea was that this basic baud has some influence. Could some one explain what it is for? Florian > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/c2b4fa84/attachment-0021.bin From rick_knight at rlknight.com Wed Aug 6 13:01:07 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:01:07 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F4F3.3020707@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > I have an application (Readerware) that uses RXTX with Javax to access the serial port. This used to work fine under previous Linux' and Java, but something has changed, I assume with Java itself , that is causing the application to fail with a link error. The application is not able to find librxtxSerialParallel.so. RXTX supplies librxtxSerial.so and librxtxParallel.so, but not librxtxSerialParallel.so. Where can I get librxtxSerialParallel.so, or do I need it? Is something else causing the lib to not be found? Thanks, Rick Knight From rick_knight at rlknight.com Wed Aug 6 13:17:55 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:17:55 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F8E3.5060400@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Thanks for the reply. The developer of the app I'm trying to use (Readerware) has sent me a copy of the comm.api and I've copied the library (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar into the proper places. When I try to run the application, I get this error... Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: /usr/lib/libSolarisSerialParallel.so: /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not little-endian (Possible cause: endianness mismatch) Caught java.lang.UnsatisfiedLinkError: com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I while loading driver com.sun.comm.SolarisDriver Is there a way around this error? Thanks again, Rick Knight From jlar310 at gmail.com Wed Aug 6 13:37:42 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 14:37:42 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899F8E3.5060400@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > The developer of the app I'm trying to use (Readerware) has sent me a > copy of the comm.api and I've copied the library > (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar > into the proper places. When I try to run the application, I get this > error... > > Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: > /usr/lib/libSolarisSerialParallel.so: > /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not > little-endian (Possible cause: endianness mismatch) > Caught java.lang.UnsatisfiedLinkError: > com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I > > while loading driver com.sun.comm.SolarisDriver > > Is there a way around this error? What host OS are you running? From your original post it looks like 32 bit Linux. The libSolarisSerialParallel.so file is for Sun Solaris and will vary depending on the underlying hardware architecture as well. Sorry for the double post Rick, but I failed to send this to the list the first time... -- Jeff From rick_knight at rlknight.com Wed Aug 6 13:44:29 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:44:29 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: <4899FF1D.9030504@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > > >> The developer of the app I'm trying to use (Readerware) has sent me a >> copy of the comm.api and I've copied the library >> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >> into the proper places. When I try to run the application, I get this >> error... >> >> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >> /usr/lib/libSolarisSerialParallel.so: >> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >> little-endian (Possible cause: endianness mismatch) >> Caught java.lang.UnsatisfiedLinkError: >> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >> >> while loading driver com.sun.comm.SolarisDriver >> >> Is there a way around this error? >> > > What host OS are you running? From your original post it looks like 32 > bit Linux. > > The libSolarisSerialParallel.so file is for Sun Solaris and will vary > depending on the underlying hardware architecture as well. > > I'm running Kubuntu Linux (debian based). It's 32 bit. Rick Knight From jlar310 at gmail.com Wed Aug 6 15:33:23 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 16:33:23 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > I don't think Sun did binary libraries for Linux in the 2.0 version. Can someone with more historical experience than I confirm that? I recently tried to port a Comm API application from Solaris sparc to Linux x86 and likewise could not get my hands on the binary libraries. I eventually just re-wrote the code to use the gnu namespace packages and rxtx 2.1. What I don't understand is why your application vendor does not provide everything you need to run their software. FYI: I have librxtxParallel.so and librxtxSerial.so installed at JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is /usr/java/default which is actually a softlink to /usr/java/jre1.6.0_05. -- Jeff From defiantlew at yahoo.com.au Wed Aug 6 16:29:33 2008 From: defiantlew at yahoo.com.au (Lew L) Date: Thu, 7 Aug 2008 08:29:33 +1000 Subject: [Rxtx] Sun's Comm API Documentation References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> Message-ID: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> As a matter of interest is the Sun Comm API documentation available somewhere? I have tried the Sun site but it seems to have been removed. Unless I have missed the documentation for RXTX? I javadocced the RXTX source but information (to me) is minimal. Somewhere I got the impression that the Sun Comm API docs is, or was, compatible with RXTX, what is the best docs to use in conjuntion with RXTX and where may the be available? Cheers Lew From rick_knight at rlknight.com Wed Aug 6 17:18:33 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:18:33 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A3149.4050306@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff I'm not sure if I posted this here or not, but when I try to build RXTX from source I get this install error... make all-am make[1]: Entering directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' make[1]: Nothing to be done for `all-am'. make[1]: Leaving directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 Can you tell me how to get past this error and get RXTX built and installed? Thanks, Rick From bboyes at systronix.com Wed Aug 6 17:40:12 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Wed, 06 Aug 2008 17:40:12 -0600 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: At 16:29 08/06/2008, Lew L wrote: >As a matter of interest is the Sun Comm API documentation available >somewhere? I have tried the Sun site but it seems to have been removed. It's in the file we have posted, link in prev email (sorry, in a huge hurry right now). Javadocs definitely there. >Unless I have missed the documentation for RXTX? I javadocced the RXTX >source but information (to me) is minimal. >Somewhere I got the impression that the Sun Comm API docs is, or was, >compatible with RXTX, what is the best docs to use in conjuntion with RXTX >and where may the be available? Yeah, this is one of my concerns/beefs. There is little documentation for RXTX and it isn't just the same as javaxcomm. I would be willing to help out writing docs for RXTX! Yes really... esp if we can fix the Bluetooth issues. best regards Bruce >Cheers >Lew > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx ------- WWW.SYSTRONIX.COM ---------- Real embedded Java and much more +1-801-534-1017 Salt Lake City, USA From rick_knight at rlknight.com Wed Aug 6 17:54:08 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:54:08 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A39A0.2090309@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff, I would like for my vendor to switch to rxtx 2.1. It would make things much easier for me. I'm not sure why he's still using the javax compatible code. He's a small operation. Re-writing the code to use gnu namespace sounds like a major overhaul. Was it? Thanks, Rick From tjarvi at qbang.org Wed Aug 6 21:35:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:35:12 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: >> >>> Jeff wrote: >>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>>> >>>> >>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things > much easier for me. I'm not sure why he's still using the javax > compatible code. He's a small operation. Re-writing the code to use gnu > namespace sounds like a major overhaul. Was it? > Hi Jeff, The changes are fairly mechanical. Imports need to change and any explicite use of the namespace needs to change such as catching an exception. The following script was made for maintaining rxtx 2.0 but can apply to other needs. It is in the contrib dir with rxtx source. #!/bin/sh # Don't use! :) # # Sat, 03 May 2003 16:45:08 Modifications from J?rg Weule # Create a ed-cmd for the change of one pattern # case $1 in gnu) X=g/javax_comm/s+javax_comm+gnu_io+g ;; javax) X=g/gnu_io/s+gnu_io+javax_comm+g ;; *) echo;echo;echo From the top rxtx directory run;echo;echo -e \\t./ChangePackage.sh gnu;echo -e \\t\\tor;echo -e \\t./ChangePackage.sh javax;echo;echo; exit 0 ;; esac # # ed will be used to keep the owner and mode of the files unchanged. # We have run the ed-script for the characters '.' '/' as well. # "tr _ $D" do the change. # find . -type f -a -print | grep -v $0 | (while read F ; do ( echo $X; echo $X| tr _ /; echo $X| tr _ .; echo w; echo q ) | ed $F 2>&1 >/dev/null done ) # # Now we do little changes at the Makefiles. Hope that all we need. # find . -name Makefile\* -a -print | (while read F ; do cat < References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: On Thu, 7 Aug 2008, Lew L wrote: > As a matter of interest is the Sun Comm API documentation available > somewhere? I have tried the Sun site but it seems to have been removed. > > Unless I have missed the documentation for RXTX? I javadocced the RXTX > source but information (to me) is minimal. > Somewhere I got the impression that the Sun Comm API docs is, or was, > compatible with RXTX, what is the best docs to use in conjuntion with RXTX > and where may the be available? > Hi Lew, The documentation on Sun's website is accurate. The changes that are problematic in 3.0 are on the backside which rxtx used to plug into. http://java.sun.com/products/javacomm/reference/api/index.html CommPortIdentifier may have some minor differences (judging by the authors notes). -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Aug 6 21:46:08 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:46:08 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > If javax.comm.properties is properly installed and you are using a 2.0 version of Sun's commapi with rxtx 2.0, you should not see the library attempt to load libSolarisSerialParallel.so. Sun CommAPI 3.0 will not work with any version of rxtx as it is hard coded to use the shared library. See the INSTALL file with rxtx-2.0 source for more help with the properties file. -- Trent Jarvi tjarvi at qbang.org From jlar310 at gmail.com Thu Aug 7 06:32:06 2008 From: jlar310 at gmail.com (Jeff) Date: Thu, 7 Aug 2008 07:32:06 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > Jeff wrote: >> >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >> wrote: >> >>> >>> Jeff wrote: >>> >>>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>> wrote: >>>> >>>> >>>> >>>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things much > easier for me. I'm not sure why he's still using the javax compatible code. > He's a small operation. Re-writing the code to use gnu namespace sounds like > a major overhaul. Was it? I found it quite easy. In fact, in order to accommodate the transition, I actually separated all of the code that deals directly with the Comm API or RXTX into a helper class. The helper class was then coded to use reflection to determine which library was available and then instantiate the necessary objects. No direct imports of either library are used. The main application just needs to get it's hands on the IO streams and need not deal directly with the libraries. Other programs may not be so simple... But this doesn't really help you unless your vendor forks over the source code... -- Jeff From rick_knight at rlknight.com Thu Aug 7 09:47:12 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Thu, 07 Aug 2008 08:47:12 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: <489B1900.10108@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >>> wrote: >>> >>> >>>> Jeff wrote: >>>> >>>> >>>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>>> copy of the comm.api and I've copied the library >>>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>>> into the proper places. When I try to run the application, I get this >>>>>> error... >>>>>> >>>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>>> /usr/lib/libSolarisSerialParallel.so: >>>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>>> little-endian (Possible cause: endianness mismatch) >>>>>> Caught java.lang.UnsatisfiedLinkError: >>>>>> >>>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>>> >>>>>> while loading driver com.sun.comm.SolarisDriver >>>>>> >>>>>> Is there a way around this error? >>>>>> >>>>>> >>>>>> >>>>> What host OS are you running? From your original post it looks like 32 >>>>> bit Linux. >>>>> >>>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>>> depending on the underlying hardware architecture as well. >>>>> >>>>> >>>>> >>>>> >>>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>>> >>>> >>>> >>> I don't think Sun did binary libraries for Linux in the 2.0 version. >>> Can someone with more historical experience than I confirm that? >>> >>> I recently tried to port a Comm API application from Solaris sparc to >>> Linux x86 and likewise could not get my hands on the binary libraries. >>> I eventually just re-wrote the code to use the gnu namespace packages >>> and rxtx 2.1. >>> >>> What I don't understand is why your application vendor does not >>> provide everything you need to run their software. >>> >>> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >>> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >>> /usr/java/default which is actually a softlink to >>> /usr/java/jre1.6.0_05. >>> >>> >>> >> Jeff, >> >> I would like for my vendor to switch to rxtx 2.1. It would make things much >> easier for me. I'm not sure why he's still using the javax compatible code. >> He's a small operation. Re-writing the code to use gnu namespace sounds like >> a major overhaul. Was it? >> > > I found it quite easy. In fact, in order to accommodate the > transition, I actually separated all of the code that deals directly > with the Comm API or RXTX into a helper class. The helper class was > then coded to use reflection to determine which library was available > and then instantiate the necessary objects. No direct imports of > either library are used. The main application just needs to get it's > hands on the IO streams and need not deal directly with the libraries. > Other programs may not be so simple... > > But this doesn't really help you unless your vendor forks over the > source code... > > Jeff, This may not help me directly, but I'm going to forward this thread to the vendor. I think he'll be open to making things work. Thanks again, Rick Knight From agusmunioz at gmail.com Thu Aug 7 16:39:51 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Thu, 7 Aug 2008 19:39:51 -0300 Subject: [Rxtx] How to send ack? Message-ID: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Hi, I'm still learning about serial communication and I have some doubts. I've got this question about how to do the following thing in rxtx. I have this hardware that connect to a PC using a serial port. These hardware receives data from a telephone line, proccess it, and then send it forward to the serial port. I've used a program named wincomm that shows what information is send it through the serial port and I have the nex behaviour: The hardware has a buffer where all data is stored, that cannot be sent it through the seria port. The program reads the first data send it by the hardware, and keep reading the same data always. There is a button in the application that says enable Ack, and when I click, then the hardware start to send all the stored information, and all the information is shown. I write a class, using rxtx that reads the serial port, and the same thing happens, it remains reading the same (first) data all the time. And I thing something like the enable Ack I'm missing. How can I do this enable Ack from my java code using rxtx? Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080807/e0a0f9a1/attachment-0019.html From ajmas at sympatico.ca Thu Aug 7 18:26:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 7 Aug 2008 20:26:41 -0400 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: <4BF42297-81E2-4BB8-A89F-1D43588379AE@sympatico.ca> On 6-Aug-08, at 19:40 , Bruce Boyes wrote: >> Unless I have missed the documentation for RXTX? I javadocced the >> RXTX >> source but information (to me) is minimal. >> Somewhere I got the impression that the Sun Comm API docs is, or was, >> compatible with RXTX, what is the best docs to use in conjuntion >> with RXTX >> and where may the be available? > > Yeah, this is one of my concerns/beefs. There is little documentation > for RXTX and it isn't just the same as javaxcomm. > > I would be willing to help out writing docs for RXTX! Yes really... > esp if we can fix the Bluetooth issues. If you want to contribute documentation then the best place to do that is the wiki. If there is anything missing or that could be improved on then please do so. If there are any points that you would like to see improved, for which you don't have the knowledge then ask on the mailing list for a volunteer. Andre From florianmanschwetus at gmx.de Fri Aug 8 03:04:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Fri, 08 Aug 2008 11:04:14 +0200 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Message-ID: <489C0C0E.2020401@gmx.de> Agustin Mu?oz schrieb: > Hi, I'm still learning about serial communication and I have some > doubts. I've got this question about how to do the following thing in rxtx. > I have this hardware that connect to a PC using a serial port. These > hardware receives data from a telephone line, proccess it, and then send > it forward to the serial port. I've used a program named wincomm that > shows what information is send it through the serial port and I have the > nex behaviour: > > The hardware has a buffer where all data is stored, that cannot be sent > it through the seria port. > The program reads the first data send it by the hardware, and keep > reading the same data always. > There is a button in the application that says enable Ack, and when I > click, then the hardware start to send all the stored information, and > all the information is shown. > > I write a class, using rxtx that reads the serial port, and the same > thing happens, it remains reading the same (first) data all the time. > And I thing something like the enable Ack I'm missing. > How can I do this enable Ack from my java code using rxtx? Afaik, a look at man ascii reveals: Okt Dez Hex Char 006 6 06 ACK So, i hope this will do the job: send(6); florian > > Thanks in advance > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/5b4965f8/attachment-0019.bin From agusmunioz at gmail.com Fri Aug 8 16:31:00 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 19:31:00 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <489C0C0E.2020401@gmx.de> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> Message-ID: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Hi Florian, thanks for the answer. By send(6) you mean to get the port OutputStream and write a 6? I try that but it didn't work. Any suggestion? Thanks On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < florianmanschwetus at gmx.de> wrote: > Agustin Mu?oz schrieb: > > Hi, I'm still learning about serial communication and I have some doubts. >> I've got this question about how to do the following thing in rxtx. >> I have this hardware that connect to a PC using a serial port. These >> hardware receives data from a telephone line, proccess it, and then send it >> forward to the serial port. I've used a program named wincomm that shows >> what information is send it through the serial port and I have the nex >> behaviour: >> >> The hardware has a buffer where all data is stored, that cannot be sent >> it through the seria port. >> The program reads the first data send it by the hardware, and keep reading >> the same data always. >> There is a button in the application that says enable Ack, and when I >> click, then the hardware start to send all the stored information, and all >> the information is shown. >> >> I write a class, using rxtx that reads the serial port, and the same thing >> happens, it remains reading the same (first) data all the time. And I thing >> something like the enable Ack I'm missing. >> How can I do this enable Ack from my java code using rxtx? >> > Afaik, a look at man ascii reveals: > Okt Dez Hex Char > 006 6 06 ACK > So, i hope this will do the job: > send(6); > > florian > >> >> Thanks in advance >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/7f3fba42/attachment-0018.html From agusmunioz at gmail.com Fri Aug 8 18:39:27 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 21:39:27 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Message-ID: <988288430808081739x7f9e7889id82591d5a9e2b4f6@mail.gmail.com> Ok, Florian, it works!! my problem was that I've been sending, through the OutputStream, the bytes of 6 as a string: out.write("6".getBytes()); but then I realized that you can write an int on an OuptuStream, so I tried that and It works: out.write(6); Thank you for the guidance!! On Fri, Aug 8, 2008 at 7:31 PM, Agustin Mu?oz wrote: > Hi Florian, thanks for the answer. By send(6) you mean to get the port > OutputStream and write a 6? > > I try that but it didn't work. > > Any suggestion? > > Thanks > > > On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < > florianmanschwetus at gmx.de> wrote: > >> Agustin Mu?oz schrieb: >> >> Hi, I'm still learning about serial communication and I have some doubts. >>> I've got this question about how to do the following thing in rxtx. >>> I have this hardware that connect to a PC using a serial port. These >>> hardware receives data from a telephone line, proccess it, and then send it >>> forward to the serial port. I've used a program named wincomm that shows >>> what information is send it through the serial port and I have the nex >>> behaviour: >>> >>> The hardware has a buffer where all data is stored, that cannot be sent >>> it through the seria port. >>> The program reads the first data send it by the hardware, and keep >>> reading the same data always. >>> There is a button in the application that says enable Ack, and when I >>> click, then the hardware start to send all the stored information, and all >>> the information is shown. >>> >>> I write a class, using rxtx that reads the serial port, and the same >>> thing happens, it remains reading the same (first) data all the time. And I >>> thing something like the enable Ack I'm missing. >>> How can I do this enable Ack from my java code using rxtx? >>> >> Afaik, a look at man ascii reveals: >> Okt Dez Hex Char >> 006 6 06 ACK >> So, i hope this will do the job: >> send(6); >> >> florian >> >>> >>> Thanks in advance >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/b918ab3d/attachment-0018.html From florianmanschwetus at gmx.de Sat Aug 9 00:45:43 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Sat, 09 Aug 2008 08:45:43 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4899667C.6010706@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> Message-ID: <489D3D17.9090209@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >> Florian Manschwetus wrote: >>> Ok, sounds fine for the receiving problem. >>> But why i have to wait after each byte when sending a command squence? >>> (the for loop in send command) >> >> Hi Florian, >> I'd imagine you probably don't! You could send all bytes in one go and >> RXTX would send them. The problem is most probably the other end: >> perhaps it has a really small buffer, some non-standard UART, or a >> crazy timing issue. If you attach a terminal to your output and send >> all the bytes of a command in one go they should appear no problem. >> >> Regards, >> Michael Erskine. >> > correct with a terminal on the other end it works, my idea was that this > basic baud has some influence. Could some one explain what it is for? > > Florian To make it more clear, my problem is that i can't use: outputStream.write(byte[]); => Beamer doesn't understand the sequence. (mostly no answer when he answers then *001) when i use this construct instead: for (int i = 0; i < command.length; i++) { this.outputStream.write(command[i]); try { Thread.sleep(25); } catch (InterruptedException e) { // TODO Auto-generated catch block e.printStackTrace(); } } it works nearly reliable. So what could it be? This Basic Baud is what exactly? Florian -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080809/692304ee/attachment-0018.bin From tjarvi at qbang.org Sat Aug 9 16:37:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Aug 2008 16:37:19 -0600 (MDT) Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489D3D17.9090209@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> <489D3D17.9090209@gmx.de> Message-ID: On Sat, 9 Aug 2008, Florian Manschwetus wrote: > Florian Manschwetus schrieb: >> Michael Erskine schrieb: >>> Florian Manschwetus wrote: >>>> Ok, sounds fine for the receiving problem. >>>> But why i have to wait after each byte when sending a command squence? >>>> (the for loop in send command) >>> >>> Hi Florian, >>> I'd imagine you probably don't! You could send all bytes in one go and >>> RXTX would send them. The problem is most probably the other end: perhaps >>> it has a really small buffer, some non-standard UART, or a crazy timing >>> issue. If you attach a terminal to your output and send all the bytes of a >>> command in one go they should appear no problem. >>> >>> Regards, >>> Michael Erskine. >>> >> correct with a terminal on the other end it works, my idea was that this >> basic baud has some influence. Could some one explain what it is for? >> >> Florian > To make it more clear, > my problem is that i can't use: > outputStream.write(byte[]); > => Beamer doesn't understand the sequence. (mostly no answer when he answers > then *001) > > when i use this construct instead: > > for (int i = 0; i < command.length; i++) { > this.outputStream.write(command[i]); > try { > Thread.sleep(25); > } catch (InterruptedException e) { > // TODO Auto-generated catch block > e.printStackTrace(); > } > } > > it works nearly reliable. > > So what could it be? This Basic Baud is what exactly? > I suspect you are using the 'moon protocol' and don't know it. RXTX enables this by default. The buffer on the other end is first in first out while reading. If the buffer is full, the bits are hand carried to the moon and burried. Then if the other side reads a couple bytes, two more bytes go into the buffer followed by more moon protocol. The resulting array of bytes the other side reads may appear to be scrambled until you go to the moon, get the bits and insert them in the right place. Flow control can prevent the default moon protocol and throttles the communiation by almost writing a byte at a time as need be. Hardware flow control is preferable but software flow control should also work. Read and write can appear to hang if the other side is not connected. This is why we don't enable them all the time. If you can't use flow control, you have to take care with the moon protocol and give the other side time to read. That is what your slower version of write is doing. -- Trent Jarvi tjarvi at qbang.org From rxtx at allenjb.me.uk Mon Aug 11 08:06:36 2008 From: rxtx at allenjb.me.uk (AllenJB) Date: Mon, 11 Aug 2008 15:06:36 +0100 Subject: [Rxtx] Disabling EV_RXFLAG Message-ID: <48A0476C.2090800@allenjb.me.uk> Hi all, I'm working with a device which does not use an EvtChar and need to disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an event mask of FD 01 00 00. The reference software I have uses FB 00 00 00. With the rxtx mask I get framing errors which I believe are caused when the EvtChar is received. Is there currently a way with rxtx (I've using rxtx from Java) to disable EV_RXFLAG? If not from Java, where would I start if I wanted to turn the EV_RXFLAG option off in the C code? I've had a grep of the rxtx source code, but I can't see where EV_RXFLAG is being set. Thanks in advance, AllenJB From tjarvi at qbang.org Mon Aug 11 14:17:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Aug 2008 14:17:27 -0600 (MDT) Subject: [Rxtx] Disabling EV_RXFLAG In-Reply-To: <48A0476C.2090800@allenjb.me.uk> References: <48A0476C.2090800@allenjb.me.uk> Message-ID: On Mon, 11 Aug 2008, AllenJB wrote: > Hi all, > > I'm working with a device which does not use an EvtChar and need to > disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an > event mask of FD 01 00 00. The reference software I have uses FB 00 00 > 00. With the rxtx mask I get framing errors which I believe are caused > when the EvtChar is received. > > Is there currently a way with rxtx (I've using rxtx from Java) to > disable EV_RXFLAG? > > If not from Java, where would I start if I wanted to turn the EV_RXFLAG > option off in the C code? I've had a grep of the rxtx source code, but I > can't see where EV_RXFLAG is being set. > > Thanks in advance, > > AllenJB Hi Allen, I'd look at termios.c::tcsetattr() and termios.c::FillDCB() -- Trent Jarvi tjarvi at qbang.org From superdadusa at gmail.com Tue Aug 12 13:57:32 2008 From: superdadusa at gmail.com (John Choi) Date: Tue, 12 Aug 2008 13:57:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. Message-ID: Hi all, Just let you all know I just start to learn Java. I have download the serial comm package and the source code from open source communities.. I was able to verify with the given message string via serial monitor. when the given message string sends to the serial port then the character return added to the end of string by default if I use "Hello World" however if I changed to something else other than "Hello, World" there is no character return add to the end of string. I thing the library download from rxtx.org has implemented for the special strings. I can do like "login\n" in the string message to make character return but I don't want to add this individual custom character for each command return in every static message string I send, Can any who have done this might help me? Basically, something like this,, Write and add function to the program write a command, Reads the respond from a serial device.. Function handles multiple messages, Write: "com open" Read: Welcome to my world" expected Write: "admin" Read: Password?, expected Write: "admin" Read: you are successfully login terminal, expected. And I need to add a separate function handler handles a character return add to the each command above. If anyone can help this I can do the reset? Thank you in advance, John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0014.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SerialIO.java Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0014.pl From Steffen.DETTMER at ingenico.com Wed Aug 13 02:16:38 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 13 Aug 2008 10:16:38 +0200 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: References: Message-ID: <20080813081638.GA25412@elberon.bln.de.ingenico.com> * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > I can do like "login\n" in the string message to make character > return but I don't want to add this individual custom character > for each command return in every static message string I send, and why not?! > Can any who have done this might help me? what's about with writing a small wrapper function adding the carriage return? However, this would be slow, because either you call write two times (very bad) or the string needs to be copied, \n appended and written (since you are using Java Performance probably isn't so critical). Personally I would write `"login\n"' and `username + "\n"' etc., because since it is part of the command it should be part of the command definition string. > Basically, something like this,, Write and add function to the program write > a command, Reads the respond from a serial device.. correctly reading a `line' is more difficult. If you cannot make assumptions about timeouts and/or you need to have low delay, you need to read byte wise. If you need to save CPU resources you might need to add some buffering layer that you can read byte-wise but that is reading blockwise with some small timeout (lets say for serial lines something around byte transmission time times three or so). > /* > * To change this template, choose Tools | Templates > * and open the template in the editor. > */ :) > package joliba; > > /** > * > * @author root > */ :) > // derived from SUN's examples in the javax.comm package > import java.io.*; > import java.util.*; > //import javax.comm.*; // for SUN's serial/parallel port libraries > import gnu.io.*; // for rxtxSerial library > > public class SerialIO implements Runnable, SerialPortEventListener { > static CommPortIdentifier portId; > static CommPortIdentifier saveportId; > static Enumeration portList; > InputStream inputStream; > SerialPort serialPort; > Thread readThread; You need a thread for your synchronous RPC-style protocol? > static String messageString = "Hello, world!"; > static OutputStream outputStream; > static boolean outputBufferEmptyFlag = false; > > public static void main(String[] args) { > boolean portFound = false; > String defaultPort; > > // determine the name of the serial port on several operating systems > String osname = System.getProperty("os.name","").toLowerCase(); > if ( osname.startsWith("windows") ) { > // windows > defaultPort = "COM1"; > } else if (osname.startsWith("linux")) { > // linux > defaultPort = "/dev/ttyS0"; > } else if ( osname.startsWith("mac") ) { > // mac > defaultPort = "????"; > } else { > System.out.println("Sorry, your operating system is not supported"); > return; > } Is such a construction recommended? Isn't there some abstraction (like COM1 working on any platform)? [...] > try { > // activate the OUTPUT_BUFFER_EMPTY notifier > serialPort.notifyOnOutputEmpty(true); > } catch (Exception e) { > System.out.println("Error setting event notification"); > System.out.println(e.toString()); > System.exit(-1); > } I doubt that -1 is defined, probably some 127 or so would be the result, maybe better simply `throw e'? > public void writetoport() { > System.out.println("Writing \""+messageString+"\" to "+serialPort.getName()); > try { > // write string to serial port > outputStream.write(messageString.getBytes()); > } catch (IOException e) {} > } maybe something like /** * Writes the given output string and an additional carriage * return to the current outputStream. */ public void writeStringToPort( /** The output string (without CR). */ String output ) throws IOException { String outputLine = output + "\n"; outputStream.write(outputLine.getBytes()); } ? > > public SerialIO() { > // initalize serial port > try { > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > } catch (PortInUseException e) {} if the port is in use, you continue? Wonder that this works in Java, I would assume serialPort beeing uninitialized which AFAIK is an error in Java. > try { > inputStream = serialPort.getInputStream(); > } catch (IOException e) {} > > try { > serialPort.addEventListener(this); > } catch (TooManyListenersException e) {} > > // activate the DATA_AVAILABLE notifier > serialPort.notifyOnDataAvailable(true); > > try { > // set port parameters > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > } catch (UnsupportedCommOperationException e) {} > > // start the read thread > readThread = new Thread(this); > readThread.start(); > > } I think in all those exception cases you can abort, because it is unlikely that ignoring those errors allow a successful continuation, so in this case maybe it would be better to add a throw clause to the method. > public void run() { > // first thing in the thread, we initialize the write operation > initwritetoport(); > try { > while (true) { > // write string to port, the serialEvent will read it > writetoport(); > Thread.sleep(1000); > } > } catch (InterruptedException e) {} > } Does this make sense? Your `SimpleReadApp' writes one and the same string each second? > public void serialEvent(SerialPortEvent event) { > switch (event.getEventType()) { > case SerialPortEvent.BI: > case SerialPortEvent.OE: > case SerialPortEvent.FE: > case SerialPortEvent.PE: > case SerialPortEvent.CD: > case SerialPortEvent.CTS: > case SerialPortEvent.DSR: > case SerialPortEvent.RI: > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > break; > case SerialPortEvent.DATA_AVAILABLE: > // we get here if data has been received > byte[] readBuffer = new byte[20]; > try { > // read data > while (inputStream.available() > 0) { > int numBytes = inputStream.read(readBuffer); > } > // print data > String result = new String(readBuffer); > System.out.println("Read: "+result); > } catch (IOException e) {} I doubt that this is correct. I would assume you will get a 20 bytes result always, if more bytes would be available they would be printed in a second line but if less bytes are read I'd assume that the buffer/result contains zero bytes from implicite readBuffer contents initialisation (zero is no string terminator in Java AFAIK). > break; > } > } > } oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From florianmanschwetus at gmx.de Wed Aug 13 06:09:31 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 13 Aug 2008 14:09:31 +0200 Subject: [Rxtx] someone has seen such errors? Message-ID: <48A2CEFB.90007@gmx.de> I mean my communication mostly works, but it is far from perfect could this be the reason? Florian Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/949b9947/attachment-0014.bin From superdadusa at gmail.com Wed Aug 13 08:40:32 2008 From: superdadusa at gmail.com (John Choi) Date: Wed, 13 Aug 2008 08:40:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: <20080813081638.GA25412@elberon.bln.de.ingenico.com> References: <20080813081638.GA25412@elberon.bln.de.ingenico.com> Message-ID: Thank you so much Steffen and I will try that suggestion. John On 8/13/08, Steffen DETTMER wrote: > > * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > > I can do like "login\n" in the string message to make character > > return but I don't want to add this individual custom character > > for each command return in every static message string I send, > > and why not?! > > > Can any who have done this might help me? > > what's about with writing a small wrapper function adding the > carriage return? > However, this would be slow, because either you call write two > times (very bad) or the string needs to be copied, \n appended > and written (since you are using Java Performance probably isn't > so critical). > > Personally I would write `"login\n"' and `username + "\n"' etc., > because since it is part of the command it should be part of the > command definition string. > > > Basically, something like this,, Write and add function to the program > write > > a command, Reads the respond from a serial device.. > > correctly reading a `line' is more difficult. If you cannot make > assumptions about timeouts and/or you need to have low delay, you > need to read byte wise. If you need to save CPU resources you > might need to add some buffering layer that you can read > byte-wise but that is reading blockwise with some small timeout > (lets say for serial lines something around byte transmission > time times three or so). > > > /* > > * To change this template, choose Tools | Templates > > * and open the template in the editor. > > */ > > :) > > > package joliba; > > > > /** > > * > > * @author root > > */ > > :) > > > // derived from SUN's examples in the javax.comm package > > import java.io.*; > > import java.util.*; > > //import javax.comm.*; // for SUN's serial/parallel port libraries > > import gnu.io.*; // for rxtxSerial library > > > > public class SerialIO implements Runnable, SerialPortEventListener { > > static CommPortIdentifier portId; > > static CommPortIdentifier saveportId; > > static Enumeration portList; > > InputStream inputStream; > > SerialPort serialPort; > > Thread readThread; > > You need a thread for your synchronous RPC-style protocol? > > > static String messageString = "Hello, world!"; > > static OutputStream outputStream; > > static boolean outputBufferEmptyFlag = false; > > > > public static void main(String[] args) { > > boolean portFound = false; > > String defaultPort; > > > > // determine the name of the serial port on several operating > systems > > String osname = System.getProperty("os.name","").toLowerCase(); > > if ( osname.startsWith("windows") ) { > > // windows > > defaultPort = "COM1"; > > } else if (osname.startsWith("linux")) { > > // linux > > defaultPort = "/dev/ttyS0"; > > } else if ( osname.startsWith("mac") ) { > > // mac > > defaultPort = "????"; > > } else { > > System.out.println("Sorry, your operating system is not > supported"); > > return; > > } > > Is such a construction recommended? Isn't there some abstraction > (like COM1 working on any platform)? > > [...] > > try { > > // activate the OUTPUT_BUFFER_EMPTY notifier > > serialPort.notifyOnOutputEmpty(true); > > } catch (Exception e) { > > System.out.println("Error setting event notification"); > > System.out.println(e.toString()); > > System.exit(-1); > > } > > I doubt that -1 is defined, probably some 127 or so would be the > result, maybe better simply `throw e'? > > > public void writetoport() { > > System.out.println("Writing \""+messageString+"\" to > "+serialPort.getName()); > > try { > > // write string to serial port > > outputStream.write(messageString.getBytes()); > > } catch (IOException e) {} > > } > > maybe something like > > /** > * Writes the given output string and an additional carriage > * return to the current outputStream. > */ > public void > writeStringToPort( > /** The output string (without CR). */ > String output > ) throws IOException > { > String outputLine = output + "\n"; > outputStream.write(outputLine.getBytes()); > } > > ? > > > > > public SerialIO() { > > // initalize serial port > > try { > > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > > } catch (PortInUseException e) {} > > if the port is in use, you continue? Wonder that this works in > Java, I would assume serialPort beeing uninitialized which AFAIK > is an error in Java. > > > try { > > inputStream = serialPort.getInputStream(); > > } catch (IOException e) {} > > > > try { > > serialPort.addEventListener(this); > > } catch (TooManyListenersException e) {} > > > > // activate the DATA_AVAILABLE notifier > > serialPort.notifyOnDataAvailable(true); > > > > try { > > // set port parameters > > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > } catch (UnsupportedCommOperationException e) {} > > > > // start the read thread > > readThread = new Thread(this); > > readThread.start(); > > > > } > > I think in all those exception cases you can abort, because it is > unlikely that ignoring those errors allow a successful > continuation, so in this case maybe it would be better to add a > throw clause to the method. > > > public void run() { > > // first thing in the thread, we initialize the write operation > > initwritetoport(); > > try { > > while (true) { > > // write string to port, the serialEvent will read it > > writetoport(); > > Thread.sleep(1000); > > } > > } catch (InterruptedException e) {} > > } > > Does this make sense? Your `SimpleReadApp' writes one and the > same string each second? > > > public void serialEvent(SerialPortEvent event) { > > switch (event.getEventType()) { > > case SerialPortEvent.BI: > > case SerialPortEvent.OE: > > case SerialPortEvent.FE: > > case SerialPortEvent.PE: > > case SerialPortEvent.CD: > > case SerialPortEvent.CTS: > > case SerialPortEvent.DSR: > > case SerialPortEvent.RI: > > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > > break; > > case SerialPortEvent.DATA_AVAILABLE: > > // we get here if data has been received > > byte[] readBuffer = new byte[20]; > > try { > > // read data > > while (inputStream.available() > 0) { > > int numBytes = inputStream.read(readBuffer); > > } > > // print data > > String result = new String(readBuffer); > > System.out.println("Read: "+result); > > } catch (IOException e) {} > > I doubt that this is correct. I would assume you will get a 20 > bytes result always, if more bytes would be available they would > be printed in a second line but if less bytes are read I'd assume > that the buffer/result contains zero bytes from implicite > readBuffer contents initialisation (zero is no string terminator > in Java AFAIK). > > > break; > > } > > } > > } > > oki, > > Steffen > > About Ingenico Throughout the world businesses rely on Ingenico for secure > and expedient electronic transaction acceptance. Ingenico products leverage > proven technology, established standards and unparalleled ergonomics to > provide optimal reliability, versatility and usability. This comprehensive > range of products is complemented by a global array of services and > partnerships, enabling businesses in a number of vertical sectors to accept > transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged > information. If you are not the addressee or authorized to receive this for > the addressee, you must not use, copy, disclose or take any action based on > this message or any information herein. If you have received this message in > error, please advise the sender immediately by reply e-mail and delete this > message. Thank you for your cooperation. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/73c4135c/attachment-0013.html From ajmas at sympatico.ca Sat Aug 16 07:15:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 09:15:41 -0400 Subject: [Rxtx] someone has seen such errors? In-Reply-To: <48A2CEFB.90007@gmx.de> References: <48A2CEFB.90007@gmx.de> Message-ID: <43B5E8DA-1D93-4D90-809B-AAF35FF724C5@sympatico.ca> On 13-Aug-08, at 08:09 , Florian Manschwetus wrote: > I mean my communication mostly works, but it is far from perfect > could this be the reason? > > Florian > > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control Judging by the error messages this looks related to the driver you are using. Do a search for the following string with you favourite search engine, it should turn up a few hits: ftdi_set_termios FAILED to set databits/stopbits/parity Andre From ajmas at sympatico.ca Sat Aug 16 19:12:04 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 21:12:04 -0400 Subject: [Rxtx] Using SerialPortEvent? Message-ID: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Hi, Could someone tell me how I should be using the SerialPortEvent? Am I meant to be waiting for data and then simply reading from the inputstream? If this is the case why no just block on an inputstream read? Andr? From tjarvi at qbang.org Sat Aug 16 19:41:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 16 Aug 2008 19:41:13 -0600 (MDT) Subject: [Rxtx] Using SerialPortEvent? In-Reply-To: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> References: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Message-ID: On Sat, 16 Aug 2008, Andre-John Mas wrote: > Hi, > > Could someone tell me how I should be using the SerialPortEvent? Am I > meant to be waiting for data and then simply reading from the > inputstream? If this is the case why no just block on an inputstream > read? > Polling for data is fine also. It really depends upon what you are trying to do. For instance, if you require x bytes before reading, you can start polling after data is available. If you read on the same thread as your GUI and are waiting for data in a read, the results may be less than desirable. Java programming is 'usually' event driven rather than polling based. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sat Aug 16 20:10:39 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 22:10:39 -0400 Subject: [Rxtx] Using SerialPortEvent? In-Reply-To: References: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Message-ID: <3E495D4C-BB28-4845-A6AB-984C9A826BDF@sympatico.ca> On 16-Aug-08, at 21:41 , Trent Jarvi wrote: > On Sat, 16 Aug 2008, Andre-John Mas wrote: > >> Hi, >> >> Could someone tell me how I should be using the SerialPortEvent? Am I >> meant to be waiting for data and then simply reading from the >> inputstream? If this is the case why no just block on an inputstream >> read? >> > > Polling for data is fine also. It really depends upon what you are > trying to do. For instance, if you require x bytes before reading, > you can start polling after data is available. If you read on the > same thread as your GUI and are waiting for data in a read, the > results may be less than desirable. > > Java programming is 'usually' event driven rather than polling based. Sounds good. I thought I would use this opportunity to provide a event based version of the TwoWaySerialComm example. Could you just validate it before I add it to the Wiki: package ajmas74.experimental; import gnu.io.CommPort; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; import gnu.io.SerialPortEvent; import gnu.io.SerialPortEventListener; import java.io.IOException; import java.io.InputStream; import java.io.OutputStream; /** * This version of the TwoWaySerialComm example makes use of the * SerialPortEventListener to avoid polling. * * @author ajmas * */ public class TwoWaySerialComm { public TwoWaySerialComm() { super(); } void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { CommPort commPort = portIdentifier.open(this.getClass().getName(),2000); if ( commPort instanceof SerialPort ) { SerialPort serialPort = (SerialPort) commPort; serialPort .setSerialPortParams (57600 ,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); (new Thread(new SerialWriter(out))).start(); serialPort.addEventListener(new SerialReader(in)); } else { System.out.println("Error: Only serial ports are handled by this example."); } } } /** * Handles the input coming from the serial port. A new line character * is treated as the end of a block in this example. */ public static class SerialReader implements SerialPortEventListener { private InputStream in; private byte[] buffer = new byte[1024]; public SerialReader ( InputStream in ) { this.in = in; } public void serialEvent(SerialPortEvent arg0) { int data; try { int len = 0; while ( ( data = in.read()) > -1 ) { if ( data != '\n' ) { break; } buffer[len++] = (byte) data; } System.out.print(new String(buffer,0,len)); } catch ( IOException e ) { e.printStackTrace(); System.exit(-1); } } } /** */ public static class SerialWriter implements Runnable { OutputStream out; public SerialWriter ( OutputStream out ) { this.out = out; } public void run () { try { int c = 0; while ( ( c = System.in.read()) > -1 ) { this.out.write(c); } } catch ( IOException e ) { e.printStackTrace(); System.exit(-1); } } } public static void main ( String[] args ) { try { (new TwoWaySerialComm()).connect("COM3"); } catch ( Exception e ) { e.printStackTrace(); } } } From lfarkas at lfarkas.org Tue Aug 19 07:32:59 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Tue, 19 Aug 2008 15:32:59 +0200 Subject: [Rxtx] JNI or CNI Message-ID: <48AACB8B.9060606@lfarkas.org> hi, what is the current recommended way to rxtx on linux JNI or it's better to use CNI? is the CNI version fully functional and the same level as the JNI? i currently try to make a rhel/centos/fedora rpm for rxtx but has many problems with the standard dir structure. yours. -- Levente "Si vis pacem para bellum!" From lfarkas at lfarkas.org Tue Aug 19 08:47:34 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Tue, 19 Aug 2008 16:47:34 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel Message-ID: <48AADD06.7040809@lfarkas.org> hi, newer or not so newer linux kernel do not contain the UTS_RELEASE so the current rxtx is not compile on the latest kernels. even if it's commented out in the cvs configure there are other places. i attcahed a patch which fix it (or at least doesn't cause error at non-debug build). ps. is there any plan to the new 2.1-8 release in the near future? there are many changes (at least the license change in all file and in this case create a diff is very difficult)? the latest release more then 2 years old:-( -- Levente "Si vis pacem para bellum!" -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-2.1-uts.patch Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080819/ab5d38ac/attachment-0007.pl From ajmas at sympatico.ca Tue Aug 19 16:21:53 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 19 Aug 2008 18:21:53 -0400 Subject: [Rxtx] Event based example Message-ID: <24735BFB-B088-4B84-8173-FE98DF63B12F@sympatico.ca> Hi, I have just posted an example of using SerialPortEventListener in the Wiki: http://rxtx.qbang.org/wiki/index.php/Event_Based_Two_Way_Communication If you see any issues please could you let me know, or makes the changes. Andre From Martin.Oberhuber at windriver.com Fri Aug 22 04:02:24 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 22 Aug 2008 12:02:24 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <48AADD06.7040809@lfarkas.org> References: <48AADD06.7040809@lfarkas.org> Message-ID: <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> Farkas, there are indeed efforts to get a new RXTX release out the door. Your experience as a package maintainer would likely be helpful during these efforts, since I'd think it makes sense to keep the patches minimal that you must make to have the source compile in your environment. What are the things that you find problematic, apart from the UTS thing that you have mentioned before? What is the timing that you have in mind for your package? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Farkas Levente > Sent: Tuesday, August 19, 2008 4:48 PM > To: rxtx at qbang.org > Subject: [Rxtx] UTS_RELEASE not defined in newer kernel > > hi, > newer or not so newer linux kernel do not contain the > UTS_RELEASE so the > current rxtx is not compile on the latest kernels. even if it's > commented out in the cvs configure there are other places. > i attcahed a patch which fix it (or at least doesn't cause error at > non-debug build). > > ps. is there any plan to the new 2.1-8 release in the near > future? there > are many changes (at least the license change in all file and in this > case create a diff is very difficult)? the latest release more then 2 > years old:-( > > -- > Levente "Si vis pacem para bellum!" > From lfarkas at lfarkas.org Fri Aug 22 04:36:26 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Fri, 22 Aug 2008 12:36:26 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> References: <48AADD06.7040809@lfarkas.org> <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> Message-ID: <48AE96AA.6090505@lfarkas.org> hi, the packages already build for fedora-9 and centos-5 and here: http://www.lfarkas.org/linux/packages/ what i've to patch, the UTS, the configure script, but it's already fixed in the cvs (in another way) and the loadlibrary. the reasons for last one can be found here: https://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_files_that_use_JNI after we test it i'd like to add these packages to fedora and epel main repository (that's why it's be useful a new release after 2 years:-) imho versions are cheap and why not just release 2.1-8? the real code changes are minimal and if something critical bug found still can release 2.1-9:-) ps. and would be better to use simple number for version like 2.1-7 rather then 2.1-7v2. Oberhuber, Martin wrote: > Farkas, > > there are indeed efforts to get a new RXTX release out the > door. Your experience as a package maintainer would likely > be helpful during these efforts, since I'd think it makes > sense to keep the patches minimal that you must make to > have the source compile in your environment. > > What are the things that you find problematic, apart from > the UTS thing that you have mentioned before? > > What is the timing that you have in mind for your package? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >> On Behalf Of Farkas Levente >> Sent: Tuesday, August 19, 2008 4:48 PM >> To: rxtx at qbang.org >> Subject: [Rxtx] UTS_RELEASE not defined in newer kernel >> >> hi, >> newer or not so newer linux kernel do not contain the >> UTS_RELEASE so the >> current rxtx is not compile on the latest kernels. even if it's >> commented out in the cvs configure there are other places. >> i attcahed a patch which fix it (or at least doesn't cause error at >> non-debug build). >> >> ps. is there any plan to the new 2.1-8 release in the near >> future? there >> are many changes (at least the license change in all file and in this >> case create a diff is very difficult)? the latest release more then 2 >> years old:-( >> >> -- >> Levente "Si vis pacem para bellum!" >> -- Levente "Si vis pacem para bellum!" From tjarvi at qbang.org Fri Aug 22 18:50:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Aug 2008 18:50:32 -0600 (MDT) Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <48AE96AA.6090505@lfarkas.org> References: <48AADD06.7040809@lfarkas.org> <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> <48AE96AA.6090505@lfarkas.org> Message-ID: Hi Farkas, The v2 was simply the second build - no code changes. We are comming out with a new release shortly. I would encourage working with distros as you are. The building of rxtx turns out to be a bottle neck in quick releases. We do want stable releases that work for a year or more but I would have no problems with quicker cycles on developing work. I would have no problem working with someone that did builds that receive less testing more often but they do have to come out for multiple platforms from this end. Thanks for the links. On Fri, 22 Aug 2008, Farkas Levente wrote: > hi, > the packages already build for fedora-9 and centos-5 and here: > http://www.lfarkas.org/linux/packages/ > what i've to patch, the UTS, the configure script, but it's already > fixed in the cvs (in another way) and the loadlibrary. the reasons for > last one can be found here: > https://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_files_that_use_JNI > after we test it i'd like to add these packages to fedora and epel main > repository (that's why it's be useful a new release after 2 years:-) > imho versions are cheap and why not just release 2.1-8? the real code > changes are minimal and if something critical bug found still can > release 2.1-9:-) > > ps. and would be better to use simple number for version like 2.1-7 > rather then 2.1-7v2. > > Oberhuber, Martin wrote: >> Farkas, >> >> there are indeed efforts to get a new RXTX release out the >> door. Your experience as a package maintainer would likely >> be helpful during these efforts, since I'd think it makes >> sense to keep the patches minimal that you must make to >> have the source compile in your environment. >> >> What are the things that you find problematic, apart from >> the UTS thing that you have mentioned before? >> >> What is the timing that you have in mind for your package? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >>> On Behalf Of Farkas Levente >>> Sent: Tuesday, August 19, 2008 4:48 PM >>> To: rxtx at qbang.org >>> Subject: [Rxtx] UTS_RELEASE not defined in newer kernel >>> >>> hi, >>> newer or not so newer linux kernel do not contain the >>> UTS_RELEASE so the >>> current rxtx is not compile on the latest kernels. even if it's >>> commented out in the cvs configure there are other places. >>> i attcahed a patch which fix it (or at least doesn't cause error at >>> non-debug build). >>> >>> ps. is there any plan to the new 2.1-8 release in the near >>> future? there >>> are many changes (at least the license change in all file and in this >>> case create a diff is very difficult)? the latest release more then 2 >>> years old:-( >>> >>> -- >>> Levente "Si vis pacem para bellum!" >>> > > > From andy at triera.net Sat Aug 23 15:17:44 2008 From: andy at triera.net (Andy Rozman) Date: Sat, 23 Aug 2008 21:17:44 +0000 Subject: [Rxtx] port not identified on FreeBSD In-Reply-To: References: Message-ID: <48B07E78.2030306@triera.net> Hi ! I have one small problem... I have started using FreeBSD in last few days and I have come accross a problem with rxtx on FreeBSD. I am using usb-to-serial converter, which is identified under FreeBSD without problem as ucom0, and creates link under /dev called ttyU0, which is correct way to be done under FreeBSD (if device would be unidentified it would be called ugen0 - as usb generic). Problem is that I say to rxtx to get my all serial ports this one is not among them. Which names are permissable under linux-like implementations? Which will be accepted as serial ports? Andy From tjarvi at qbang.org Sat Aug 23 13:57:45 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 23 Aug 2008 13:57:45 -0600 (MDT) Subject: [Rxtx] port not identified on FreeBSD In-Reply-To: <48B07E78.2030306@triera.net> References: <48B07E78.2030306@triera.net> Message-ID: On Sat, 23 Aug 2008, Andy Rozman wrote: > Hi ! > > I have one small problem... I have started using FreeBSD in last few > days and I have come accross a problem with rxtx on FreeBSD. > > I am using usb-to-serial converter, which is identified under FreeBSD > without problem as ucom0, and creates link under /dev called > ttyU0, which is correct way to be done under FreeBSD (if device would be > unidentified it would be called ugen0 - as usb generic). Problem is that > I say to rxtx to get my all serial ports this one is not among them. > Which names are permissable under linux-like implementations? Which will > be accepted as serial ports? > > Andy > Thanks Andy! We will add ttyU* to FreeBSD. For now you can use properties to enable the port. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting#How_does_rxtx_detect_ports.3F__Can_I_override_it.3F The fix: diff -u -r1.16.2.59 RXTXCommDriver.java --- RXTXCommDriver.java 18 Nov 2007 22:32:41 -0000 1.16.2.59 +++ RXTXCommDriver.java 23 Aug 2008 19:55:25 -0000 @@ -644,6 +644,7 @@ { String[] Temp = { "ttyd", //general purpose serial ports + "ttyU", //general purpose USB serial ports "cuaa", //dialout serial ports "ttyA", //Specialix SI/XIO dialin ports "cuaA", //Specialix SI/XIO dialout ports -- Trent Jarvi tjarvi at qbang.org From rick_knight at rlknight.com Mon Aug 4 13:25:10 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Mon, 04 Aug 2008 12:25:10 -0700 Subject: [Rxtx] Sun's Comm API? Message-ID: <48975796.4010600@rlknight.com> I have an application that requires the javax compatible version of RXTX and Sun's comm api. I've been able to download and extract the version of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api anywhere. Can someone tell me where I can find it? Or maybe send me a copy? Also, when I try to build RXTX, configure and make complete successfully but make install failes with this error libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 I've never come accross this error before. How can I get past it? Thanks, Rick From bboyes at systronix.com Mon Aug 4 19:10:01 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:10:01 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48975796.4010600@rlknight.com> References: <48975796.4010600@rlknight.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/cb9c6167/attachment-0023.html From bboyes at systronix.com Mon Aug 4 19:12:37 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:12:37 -0600 Subject: [Rxtx] Towards an RXTX release - CSR BT/USB chipset In-Reply-To: <488FB7E7.8000802@gmail.com> References: <460801A4097E3D4CA04CC64EE648584806C56CF0@ism-mail03.corp.ad.wrs.com> <13557-75390@sneakemail.com> <20980-23424@sneakemail.com> <488FB7E7.8000802@gmail.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/52236088/attachment-0023.html From tjarvi at qbang.org Mon Aug 4 19:42:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 19:42:21 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: On Mon, 4 Aug 2008, Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: > I have an application that requires the javax compatible > version of RXTX > and Sun's comm api. I've been able to download and extract > the version > of RXTX that I need (2.0-7pre2) but I can't find Sun's camm > api > anywhere. Can someone tell me where I can find it? Or maybe > send me a > > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm port > support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have just > a ZIP with only the .class JAR file - no source or docs), has a readme > with these comments: > > This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release.? The 2.0.3 release itself is > no longer distributed.? comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project.? The RxTx project (http://www.rxtx.org ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org) was opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support.? Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins.? Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > ? > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > I hope that is helpful! > It would be nice to work with Sun to resolve those longstanding issues. But it may not be practical unless the process goes as fast and painless as the grandfathering of commapi did. Another option may be the old kaffe extensions that moved to gnu classpathx. These don't have the native libraries but should provide the 2.0 interface and the javax.comm.properties mechansim for SPI. http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Mon Aug 4 20:23:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Mon, 04 Aug 2008 20:23:57 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4897B9BD.5070809@ergotech.com> Has there been any work/would it be possible, to layer a javacomm look-alike on top of the GNU code? The goal is not to move the javax code forward, but to emulate the "legacy" javax packages for people who still need this. Jim Trent Jarvi wrote: > On Mon, 4 Aug 2008, Bruce Boyes wrote: > >> At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible >> version of RXTX >> and Sun's comm api. I've been able to download and extract >> the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm >> api >> anywhere. Can someone tell me where I can find it? Or maybe >> send me a >> >> >> javaxcomm has had a sort of on-again off-again history. The windoze >> version has been languishing for years (literally) but there are newer >> versions for other OS's. >> >> We try to keep links on one of our help pages current: >> http://www.practicalembeddedjava.com/tools/javatools_list.html >> which gets you to here: >> http://java.sun.com/products/javacomm/ >> where it says in fact they no longer even support Windows and Mac: >> "Implementations of the API are currently available for Solaris SPARC, >> Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so >> someone could support it. But I guess that's part of the reason RXTX >> exists! >> >> So one of Sun's own products, SunSPOT, has to use RXTX to get comm port >> support. >> >> The version we use is 2.0 from 11/15/1998. I have posted it on our >> website, which is within the terms of the license agreement contained >> therein (as I understand it). >> >> The last version of javaxcomm for Windows, 2.0.3, (for which I have just >> a ZIP with only the .class JAR file - no source or docs), has a readme >> with these comments: >> >> This distribution contains the comm.jar file original part >> of the COMMAPI 2.0.3 release. The 2.0.3 release itself is >> no longer distributed. comm.jar, which contains the comm >> API java class files (eg. Sun's binary implementation of the >> interface classes), is being made available, unsupported, >> with no obligation to fix bugs, at the request of the RXTX >> project. The RxTx project (http://www.rxtx.org ), uses the >> comm.jar class files, but provides their own native library >> components to provide support for other platforms. >> >> The 2.0.3 comm.jar is being provided in this way because >> as of COMMAPI 3.x, the java binary implementation forked and >> became incompatible with the RxTx project's native code. >> Due to the lack of a clear business case, and to resource >> constraints, no additional resources are being >> provided to provide an alternative engineering solution >> at the time of writing. >> >> RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: >> >> Ultimately the COMMAPI would be better served if a Java >> Community Process JSR (http://www.jcp.org) was opened and >> the COMMAPI was rearchitected to provide a more pluggable >> framework to improve cross-platform support. Such an >> architecture would embody a better defined and better >> documented SPI interface, including a way for comm. ports >> to be revealed to the client application through the API >> via platform-aware plugins. Similarly, native code used >> to access comm port in general could be handled more >> flexibly using a plugin model, whereby on any platform, >> multiple native modules could be in use simultaneously. >> >> Since there are now various ways serial ports can be implemented >> and accessed, modular comm. port JNI native libraries would be >> of benefit insofar as removing the burden of over-generalization >> from any single native component, or inversely, by relieving the >> implicit constraint that comm. drivers be accessed only via a >> monolithic mechanism, such as the UNIX vnode interface. >> >> paul.klissner at sun.com >> 6/10/06 >> >> I hope that is helpful! >> > > It would be nice to work with Sun to resolve those longstanding issues. > But it may not be practical unless the process goes as fast and painless > as the grandfathering of commapi did. > > Another option may be the old kaffe extensions that moved to gnu > classpathx. These don't have the native libraries but should provide > the 2.0 interface and the javax.comm.properties mechansim for SPI. > > http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Mon Aug 4 21:09:15 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 21:09:15 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? Message-ID: Hi Jim, I will not step into the javax.comm namespace without Sun's explicite permission. I fully understand the pain point you are trying to address. In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm Linux) - which remains an integral part of rxtx. At the time it was a win for Sun and rxtx. The Sun commapi license is/was fairly clear that rxtx should not step into that namespace. It made sense as Sun was active in that space and rxtx may go into another namespace - it was an experiment in working with Sun. This may sound silly looking at something that happened almost 10 years ago. In a community of respect which Sun helped create, there is no question about what to do. I hope eventually Sun will step up and do a right thing too. I agree that this is hurting the API more than helping it. There are also questions about how to replace the API in the long term which includes HID support which isn't going well so far. Others that can't even look at Sun's javax.comm today and can look at Kaffe's contribution to classpathx can easily work around such restrictions. On Mon, 4 Aug 2008, Jim Redman wrote: > Has there been any work/would it be possible, to layer a javacomm > look-alike on top of the GNU code? > > The goal is not to move the javax code forward, but to emulate the > "legacy" javax packages for people who still need this. > > Jim > > Trent Jarvi wrote: >> >> It would be nice to work with Sun to resolve those longstanding issues. >> But it may not be practical unless the process goes as fast and painless >> as the grandfathering of commapi did. >> >> Another option may be the old kaffe extensions that moved to gnu >> classpathx. These don't have the native libraries but should provide >> the 2.0 interface and the javax.comm.properties mechansim for SPI. >> >> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From florianmanschwetus at gmx.de Tue Aug 5 05:04:46 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 13:04:46 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: References: <48971C1F.9020806@gmx.de> Message-ID: <489833CE.1040801@gmx.de> Just look at sendCommand in this method I have to place a Thread.sleep(20) after each byte send to get working. Even the event based receive doesn't work fine but this could be may stupidness. The specifikation document (it is on the last pages of the manual) for the beamer could be found on: http://www.optoma.co.uk/support.aspx Florian Manschwetus Trent Jarvi schrieb: > > Hi Florian > > Sorry for the top post in advance. I worry you may not see my answer > under all your code :) > > I have not received this email before. This is 500k of code which I > don't have time to read. I can spend about 5 min on each hobby email > and still get to work in the morning. I have a couple suggestions for > how to get an answer. > > First, cut out your comments and extra code so you can demonstrate the > question (I might even glance and see what is wrong then). Don't go for > a working final product. Isolate the problem using a simple program and > then ask with that as an example. If I did what you just did, I'd have > to post 3/4 of a million lines of code :) > > Second, join the rxtx mail-list and ask there. This will give you 100x > more eyes. I'll also read and try to follow. > > -- > taj > > > > On Mon, 4 Aug 2008, Florian Manschwetus wrote: > >> It could be that my university account is blocked by filters so >> resending from here. >> >> >> Topic is to control Optoma HD80 beamer using rs232 serial chat. >> This code is able to detect power state and switch the beamer on / off. >> connected is the beamer using a digitus usb 2.0 serial adapter with an >> FT232 USB-Serial adapter the systems architecture is amd64. >> >> Please take a look in the sendCommand routine i have to place theire >> those Thread.sleep to get it working. >> Now the question is this correct or is there a better way to get this >> working correctly? >> >> In the javadoc coming with the install i found this: >> setBaudBase >> >> public boolean setBaudBase(int BaudBase) >> throws UnsupportedCommOperationException, >> java.io.IOException >> >> Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 >> before using. >> >> could this explain the error? >> I attached my java source and the protocol description for the beamer >> (available on vendor website). >> >> thx, >> Florian Manschwetus >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: TestRS232.java Type: text/x-java Size: 9143 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0046.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0047.bin From michael.erskine at ketech.com Tue Aug 5 05:53:49 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Tue, 5 Aug 2008 12:53:49 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489833CE.1040801@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> > Just look at sendCommand in this method I have to place a > Thread.sleep(20) after each byte send to get working. Even the event > based receive doesn't work fine but this could be may stupidness. Hi Florian, Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. Regards, Michael Erskine. From florianmanschwetus at gmx.de Tue Aug 5 07:28:15 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:28:15 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> Message-ID: <4898556F.8000208@gmx.de> Michael Erskine schrieb: >> Just look at sendCommand in this method I have to place a >> Thread.sleep(20) after each byte send to get working. Even the event >> based receive doesn't work fine but this could be may stupidness. > > Hi Florian, > > Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. > > Regards, > Michael Erskine. > Ok, sounds fine for the receiving problem. But why i have to wait after each byte when sending a command squence? (the for loop in send command) Florian > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/284f350c/attachment-0022.bin From florianmanschwetus at gmx.de Tue Aug 5 07:44:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:44:14 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <4898592E.2020908@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >>> Just look at sendCommand in this method I have to place a >>> Thread.sleep(20) after each byte send to get working. Even the event >>> based receive doesn't work fine but this could be may stupidness. >> >> Hi Florian, >> >> Yes, naturally you'll have to wait for a response from the other end. >> Why not wait for notification from the event thread perhaps using a >> BlockingDeque rather than your LinkedList. Generally I >> try to decouple all input and output streams: in your case your >> application is operating synchronously like the "expect" program >> (http://expect.nist.gov/) so waits (or timeouts) will need to be >> factored in. >> >> Regards, >> Michael Erskine. >> > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) > > Florian Furthermore there is this basic baud with this confusing javadoc entry: public boolean setBaudBase(int BaudBase) throws UnsupportedCommOperationException, java.io.IOException Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 before using. maybe this could explain something Florian >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/006c7425/attachment-0022.bin From jredman at ergotech.com Tue Aug 5 09:13:36 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 05 Aug 2008 09:13:36 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: Message-ID: <48986E20.3060104@ergotech.com> Trent, So two issues: 1) Technically I'm still not sure how easy/practical a layer would be. The problems are always classes like listeners, and wrapping returns of gnu.io classes. I really see it as a "delegate" type of concept. Any thoughts or ideas of the practicality of this approach? The idea is not to modify RXTX. 2) Javax. The javax namespace does seem to be in widespread use outside of Sun (the same is true for the java namespace). The classpath extensions, or some other location, should be interested in a JavaComm implementation even if it does have dependencies on RXTX. Would you have any philosophical objection to an approach like that? Of course, I suspect it might be better if someone with that authority at Sun would admit that the javax namespace is already in the wild and that there is no problem with it being used within RXTX. Jim Trent Jarvi wrote: > Hi Jim, > > I will not step into the javax.comm namespace without Sun's explicite > permission. I fully understand the pain point you are trying to address. > > In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm > Linux) - which remains an integral part of rxtx. At the time it was a win for > Sun and rxtx. > > The Sun commapi license is/was fairly clear that rxtx should not step into that > namespace. It made sense as Sun was active in that space and rxtx may go into > another namespace - it was an experiment in working with Sun. > > This may sound silly looking at something that happened almost 10 years ago. > In a community of respect which Sun helped create, there is no question about > what to do. I hope eventually Sun will step up and do a right thing too. > > I agree that this is hurting the API more than helping it. There are also > questions about how to replace the API in the long term which includes HID > support which isn't going well so far. > > Others that can't even look at Sun's javax.comm today and can look at Kaffe's > contribution to classpathx can easily work around such restrictions. > > On Mon, 4 Aug 2008, Jim Redman wrote: > >> Has there been any work/would it be possible, to layer a javacomm >> look-alike on top of the GNU code? >> >> The goal is not to move the javax code forward, but to emulate the >> "legacy" javax packages for people who still need this. >> >> Jim >> >> Trent Jarvi wrote: >>> It would be nice to work with Sun to resolve those longstanding issues. >>> But it may not be practical unless the process goes as fast and painless >>> as the grandfathering of commapi did. >>> >>> Another option may be the old kaffe extensions that moved to gnu >>> classpathx. These don't have the native libraries but should provide >>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>> >>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From sandeep at genevasoftech.com Tue Aug 5 11:18:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Tue, 05 Aug 2008 22:48:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <48988B6C.5080409@genevasoftech.com> Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. *-- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/ad20f1cb/attachment-0022.html From Martin.Oberhuber at windriver.com Tue Aug 5 13:30:17 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Tue, 5 Aug 2008 21:30:17 +0200 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Sandeep, shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on Sol7 but I've successfully run it on Sol9 and Sol10. Or is your request really about a native 64bit variant? I'm afraid that then you're out of luck since I think that quite a bit of RXTX is not yet ready for 64 bit. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Sandeep Kumar K Sent: Tuesday, August 05, 2008 7:19 PM To: rxtx at qbang.org Subject: [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so for Solaris 9 Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. -- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/81b7f988/attachment-0022.html From tjarvi at qbang.org Tue Aug 5 22:38:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 22:38:34 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 5 Aug 2008, Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built > on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid that > then > you're out of luck since I think that quite a bit of RXTX is not yet > ready > for 64 bit. > While rxtx-2.1-7 probably has problems, The CVS code should be OK for 64 bit Solaris. If it isn't, let me know and I'll find which patch is missing. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Aug 5 23:13:00 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 23:13:00 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48986E20.3060104@ergotech.com> References: <48986E20.3060104@ergotech.com> Message-ID: On Tue, 5 Aug 2008, Jim Redman wrote: > Trent, > > So two issues: > > 1) Technically I'm still not sure how easy/practical a layer would be. The > problems are always classes like listeners, and wrapping returns of gnu.io > classes. I really see it as a "delegate" type of concept. Any thoughts or > ideas of the practicality of this approach? The idea is not to modify RXTX. I have not put too much thought into this. I assume you want what rxtx 2.0 provided to tie into javax.comm implementations. More classes could be added to rxtx 2.1-7 for SPI support. Maintaining rxtx-2.0 could also be handed to someone if they like. > > 2) Javax. The javax namespace does seem to be in widespread use outside of > Sun (the same is true for the java namespace). The classpath extensions, or > some other location, should be interested in a JavaComm implementation even > if it does have dependencies on RXTX. Would you have any philosophical > objection to an approach like that? > No problems. Classpathx would be a possible place to do it. I'd suggest thinking twice about what this involves in practical terms. You would be wanting to revive the 2.0 API while Sun is at 3.0 and grandfathering the JSR. This undermines the main reason (established api) for using the javax.comm namespace and does not leave such a project in a good position. The only win I see here is maintaining support for applications that can't migrate namespaces. Not that that isn't important. At some point it is going to be less work to just edit the bytecode :) Such a javax.comm effort would also be signing up new projects that decided to use the work up for concerns they probably will not understand or expect. That probably isn't a good path to facilitate for new projects at this time. We will put a good faith effort to work well with others but keep in mind the project has limited bandwidth for such efforts. > Of course, I suspect it might be better if someone with that authority at Sun > would admit that the javax namespace is already in the wild and that there is > no problem with it being used within RXTX. > > Jim > > Trent Jarvi wrote: >> Hi Jim, >> >> I will not step into the javax.comm namespace without Sun's explicite >> permission. I fully understand the pain point you are trying to address. >> >> In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java >> Comm Linux) - which remains an integral part of rxtx. At the time it was a >> win for Sun and rxtx. >> >> The Sun commapi license is/was fairly clear that rxtx should not step into >> that namespace. It made sense as Sun was active in that space and rxtx may >> go into another namespace - it was an experiment in working with Sun. >> >> This may sound silly looking at something that happened almost 10 years >> ago. In a community of respect which Sun helped create, there is no >> question about what to do. I hope eventually Sun will step up and do a >> right thing too. >> >> I agree that this is hurting the API more than helping it. There are also >> questions about how to replace the API in the long term which includes HID >> support which isn't going well so far. >> >> Others that can't even look at Sun's javax.comm today and can look at >> Kaffe's contribution to classpathx can easily work around such >> restrictions. >> >> On Mon, 4 Aug 2008, Jim Redman wrote: >> >>> Has there been any work/would it be possible, to layer a javacomm >>> look-alike on top of the GNU code? >>> >>> The goal is not to move the javax code forward, but to emulate the >>> "legacy" javax packages for people who still need this. >>> >>> Jim >>> >>> Trent Jarvi wrote: >>>> It would be nice to work with Sun to resolve those longstanding issues. >>>> But it may not be practical unless the process goes as fast and painless >>>> as the grandfathering of commapi did. >>>> >>>> Another option may be the old kaffe extensions that moved to gnu >>>> classpathx. These don't have the native libraries but should provide >>>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>>> >>>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From sandeep at genevasoftech.com Wed Aug 6 00:03:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Wed, 06 Aug 2008 11:33:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: <48993EB8.30107@genevasoftech.com> Thank you Mr. Martin for your suggestion. The native file which is given in rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am getting the following error . Any suggestions to solve this issue. I am using Solaris SPARC 64 bit machine. ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) thrown while loading gnu.io.RXTXCommDriver Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(Unknown Source) at java.lang.ClassLoader.loadLibrary(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) at com.ReadFromModem.main(ReadFromModem.java:84) * * *Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid > that then > you're out of luck since I think that quite a bit of RXTX is not yet ready > for 64 bit. > > Cheers, > -- > *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > ------------------------------------------------------------------------ > *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On > Behalf Of *Sandeep Kumar K > *Sent:* Tuesday, August 05, 2008 7:19 PM > *To:* rxtx at qbang.org > *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so > for Solaris 9 > > Hi, > > Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 > bit machine. The librxtxSerial.so given in website is for Solaris 8. > > *-- > > Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/1e920343/attachment-0022.html From tjarvi at qbang.org Wed Aug 6 00:21:42 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 00:21:42 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <48993EB8.30107@genevasoftech.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> <48993EB8.30107@genevasoftech.com> Message-ID: Hi Sandeep You may be out of luck unless you can compile the 2.1 src in CVS (requires gnu make and gcc). But you could try the ToyBox(R)(TM) which is a collection of WiLdLy untested cross compiled 2.1-7 binaries covering everything from the ibm z series to embeded arm/ppc. To give an idea how poorly these are tested, I don't even know if z series machines have a serial port. ftp://www.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Solaris They should at least match the binary types. Actually, I think if you use the rxtx jar from CVS with that file, it should 'work' as the fix for 64 bits was in java not the native code. You could just cd rxtx*/src; javac *.java then jar -cf RXTXcomm.jar `find -name \*.class` to create the hybrid which will complain about version information a bit. On Wed, 6 Aug 2008, Sandeep Kumar K wrote: > Thank you Mr. Martin for your suggestion. The native file which is given in > rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am > getting the following error . > Any suggestions to solve this issue. > I am using Solaris SPARC 64 bit machine. > > ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar > java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 > (Possible cause: architecture word > width mismatch) thrown while loading gnu.io.RXTXCommDriver > Exception in thread "main" java.lang.UnsatisfiedLinkError: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF > class: ELFCLASS64 (Possible cause: > architecture word width mismatch) > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(Unknown Source) > at java.lang.ClassLoader.loadLibrary(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > at com.ReadFromModem.main(ReadFromModem.java:84) > > * > * > > *Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > > > Oberhuber, Martin wrote: >> Sandeep, >> shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse >> variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on >> Sol7 but I've successfully run it on Sol9 and Sol10. >> Or is your request really about a native 64bit variant? I'm afraid that >> then >> you're out of luck since I think that quite a bit of RXTX is not yet ready >> for 64 bit. >> Cheers, >> -- >> *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> ------------------------------------------------------------------------ >> *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On >> Behalf Of *Sandeep Kumar K >> *Sent:* Tuesday, August 05, 2008 7:19 PM >> *To:* rxtx at qbang.org >> *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so >> for Solaris 9 >> >> Hi, >> >> Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 >> bit machine. The librxtxSerial.so given in website is for Solaris 8. >> >> *-- >> Thanks & Regards >> >> Sandeep Kumar K >> Sr. Software Engineer >> Geneva Software Technologies >> Whitefield, Bangalore >> Mob : 9880193454* >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> From michael.erskine at ketech.com Wed Aug 6 01:39:28 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 6 Aug 2008 08:39:28 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Florian Manschwetus wrote: > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) Hi Florian, I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. Regards, Michael Erskine. From florianmanschwetus at gmx.de Wed Aug 6 02:53:16 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 06 Aug 2008 10:53:16 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Message-ID: <4899667C.6010706@gmx.de> Michael Erskine schrieb: > Florian Manschwetus wrote: >> Ok, sounds fine for the receiving problem. >> But why i have to wait after each byte when sending a command squence? >> (the for loop in send command) > > Hi Florian, > I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. > > Regards, > Michael Erskine. > correct with a terminal on the other end it works, my idea was that this basic baud has some influence. Could some one explain what it is for? Florian > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/c2b4fa84/attachment-0022.bin From rick_knight at rlknight.com Wed Aug 6 13:01:07 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:01:07 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F4F3.3020707@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > I have an application (Readerware) that uses RXTX with Javax to access the serial port. This used to work fine under previous Linux' and Java, but something has changed, I assume with Java itself , that is causing the application to fail with a link error. The application is not able to find librxtxSerialParallel.so. RXTX supplies librxtxSerial.so and librxtxParallel.so, but not librxtxSerialParallel.so. Where can I get librxtxSerialParallel.so, or do I need it? Is something else causing the lib to not be found? Thanks, Rick Knight From rick_knight at rlknight.com Wed Aug 6 13:17:55 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:17:55 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F8E3.5060400@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Thanks for the reply. The developer of the app I'm trying to use (Readerware) has sent me a copy of the comm.api and I've copied the library (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar into the proper places. When I try to run the application, I get this error... Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: /usr/lib/libSolarisSerialParallel.so: /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not little-endian (Possible cause: endianness mismatch) Caught java.lang.UnsatisfiedLinkError: com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I while loading driver com.sun.comm.SolarisDriver Is there a way around this error? Thanks again, Rick Knight From jlar310 at gmail.com Wed Aug 6 13:37:42 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 14:37:42 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899F8E3.5060400@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > The developer of the app I'm trying to use (Readerware) has sent me a > copy of the comm.api and I've copied the library > (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar > into the proper places. When I try to run the application, I get this > error... > > Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: > /usr/lib/libSolarisSerialParallel.so: > /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not > little-endian (Possible cause: endianness mismatch) > Caught java.lang.UnsatisfiedLinkError: > com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I > > while loading driver com.sun.comm.SolarisDriver > > Is there a way around this error? What host OS are you running? From your original post it looks like 32 bit Linux. The libSolarisSerialParallel.so file is for Sun Solaris and will vary depending on the underlying hardware architecture as well. Sorry for the double post Rick, but I failed to send this to the list the first time... -- Jeff From rick_knight at rlknight.com Wed Aug 6 13:44:29 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:44:29 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: <4899FF1D.9030504@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > > >> The developer of the app I'm trying to use (Readerware) has sent me a >> copy of the comm.api and I've copied the library >> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >> into the proper places. When I try to run the application, I get this >> error... >> >> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >> /usr/lib/libSolarisSerialParallel.so: >> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >> little-endian (Possible cause: endianness mismatch) >> Caught java.lang.UnsatisfiedLinkError: >> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >> >> while loading driver com.sun.comm.SolarisDriver >> >> Is there a way around this error? >> > > What host OS are you running? From your original post it looks like 32 > bit Linux. > > The libSolarisSerialParallel.so file is for Sun Solaris and will vary > depending on the underlying hardware architecture as well. > > I'm running Kubuntu Linux (debian based). It's 32 bit. Rick Knight From jlar310 at gmail.com Wed Aug 6 15:33:23 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 16:33:23 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > I don't think Sun did binary libraries for Linux in the 2.0 version. Can someone with more historical experience than I confirm that? I recently tried to port a Comm API application from Solaris sparc to Linux x86 and likewise could not get my hands on the binary libraries. I eventually just re-wrote the code to use the gnu namespace packages and rxtx 2.1. What I don't understand is why your application vendor does not provide everything you need to run their software. FYI: I have librxtxParallel.so and librxtxSerial.so installed at JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is /usr/java/default which is actually a softlink to /usr/java/jre1.6.0_05. -- Jeff From defiantlew at yahoo.com.au Wed Aug 6 16:29:33 2008 From: defiantlew at yahoo.com.au (Lew L) Date: Thu, 7 Aug 2008 08:29:33 +1000 Subject: [Rxtx] Sun's Comm API Documentation References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> Message-ID: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> As a matter of interest is the Sun Comm API documentation available somewhere? I have tried the Sun site but it seems to have been removed. Unless I have missed the documentation for RXTX? I javadocced the RXTX source but information (to me) is minimal. Somewhere I got the impression that the Sun Comm API docs is, or was, compatible with RXTX, what is the best docs to use in conjuntion with RXTX and where may the be available? Cheers Lew From rick_knight at rlknight.com Wed Aug 6 17:18:33 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:18:33 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A3149.4050306@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff I'm not sure if I posted this here or not, but when I try to build RXTX from source I get this install error... make all-am make[1]: Entering directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' make[1]: Nothing to be done for `all-am'. make[1]: Leaving directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 Can you tell me how to get past this error and get RXTX built and installed? Thanks, Rick From bboyes at systronix.com Wed Aug 6 17:40:12 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Wed, 06 Aug 2008 17:40:12 -0600 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: At 16:29 08/06/2008, Lew L wrote: >As a matter of interest is the Sun Comm API documentation available >somewhere? I have tried the Sun site but it seems to have been removed. It's in the file we have posted, link in prev email (sorry, in a huge hurry right now). Javadocs definitely there. >Unless I have missed the documentation for RXTX? I javadocced the RXTX >source but information (to me) is minimal. >Somewhere I got the impression that the Sun Comm API docs is, or was, >compatible with RXTX, what is the best docs to use in conjuntion with RXTX >and where may the be available? Yeah, this is one of my concerns/beefs. There is little documentation for RXTX and it isn't just the same as javaxcomm. I would be willing to help out writing docs for RXTX! Yes really... esp if we can fix the Bluetooth issues. best regards Bruce >Cheers >Lew > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx ------- WWW.SYSTRONIX.COM ---------- Real embedded Java and much more +1-801-534-1017 Salt Lake City, USA From rick_knight at rlknight.com Wed Aug 6 17:54:08 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:54:08 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A39A0.2090309@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff, I would like for my vendor to switch to rxtx 2.1. It would make things much easier for me. I'm not sure why he's still using the javax compatible code. He's a small operation. Re-writing the code to use gnu namespace sounds like a major overhaul. Was it? Thanks, Rick From tjarvi at qbang.org Wed Aug 6 21:35:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:35:12 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: >> >>> Jeff wrote: >>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>>> >>>> >>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things > much easier for me. I'm not sure why he's still using the javax > compatible code. He's a small operation. Re-writing the code to use gnu > namespace sounds like a major overhaul. Was it? > Hi Jeff, The changes are fairly mechanical. Imports need to change and any explicite use of the namespace needs to change such as catching an exception. The following script was made for maintaining rxtx 2.0 but can apply to other needs. It is in the contrib dir with rxtx source. #!/bin/sh # Don't use! :) # # Sat, 03 May 2003 16:45:08 Modifications from J?rg Weule # Create a ed-cmd for the change of one pattern # case $1 in gnu) X=g/javax_comm/s+javax_comm+gnu_io+g ;; javax) X=g/gnu_io/s+gnu_io+javax_comm+g ;; *) echo;echo;echo From the top rxtx directory run;echo;echo -e \\t./ChangePackage.sh gnu;echo -e \\t\\tor;echo -e \\t./ChangePackage.sh javax;echo;echo; exit 0 ;; esac # # ed will be used to keep the owner and mode of the files unchanged. # We have run the ed-script for the characters '.' '/' as well. # "tr _ $D" do the change. # find . -type f -a -print | grep -v $0 | (while read F ; do ( echo $X; echo $X| tr _ /; echo $X| tr _ .; echo w; echo q ) | ed $F 2>&1 >/dev/null done ) # # Now we do little changes at the Makefiles. Hope that all we need. # find . -name Makefile\* -a -print | (while read F ; do cat < References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: On Thu, 7 Aug 2008, Lew L wrote: > As a matter of interest is the Sun Comm API documentation available > somewhere? I have tried the Sun site but it seems to have been removed. > > Unless I have missed the documentation for RXTX? I javadocced the RXTX > source but information (to me) is minimal. > Somewhere I got the impression that the Sun Comm API docs is, or was, > compatible with RXTX, what is the best docs to use in conjuntion with RXTX > and where may the be available? > Hi Lew, The documentation on Sun's website is accurate. The changes that are problematic in 3.0 are on the backside which rxtx used to plug into. http://java.sun.com/products/javacomm/reference/api/index.html CommPortIdentifier may have some minor differences (judging by the authors notes). -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Aug 6 21:46:08 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:46:08 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > If javax.comm.properties is properly installed and you are using a 2.0 version of Sun's commapi with rxtx 2.0, you should not see the library attempt to load libSolarisSerialParallel.so. Sun CommAPI 3.0 will not work with any version of rxtx as it is hard coded to use the shared library. See the INSTALL file with rxtx-2.0 source for more help with the properties file. -- Trent Jarvi tjarvi at qbang.org From jlar310 at gmail.com Thu Aug 7 06:32:06 2008 From: jlar310 at gmail.com (Jeff) Date: Thu, 7 Aug 2008 07:32:06 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > Jeff wrote: >> >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >> wrote: >> >>> >>> Jeff wrote: >>> >>>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>> wrote: >>>> >>>> >>>> >>>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things much > easier for me. I'm not sure why he's still using the javax compatible code. > He's a small operation. Re-writing the code to use gnu namespace sounds like > a major overhaul. Was it? I found it quite easy. In fact, in order to accommodate the transition, I actually separated all of the code that deals directly with the Comm API or RXTX into a helper class. The helper class was then coded to use reflection to determine which library was available and then instantiate the necessary objects. No direct imports of either library are used. The main application just needs to get it's hands on the IO streams and need not deal directly with the libraries. Other programs may not be so simple... But this doesn't really help you unless your vendor forks over the source code... -- Jeff From rick_knight at rlknight.com Thu Aug 7 09:47:12 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Thu, 07 Aug 2008 08:47:12 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: <489B1900.10108@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >>> wrote: >>> >>> >>>> Jeff wrote: >>>> >>>> >>>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>>> copy of the comm.api and I've copied the library >>>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>>> into the proper places. When I try to run the application, I get this >>>>>> error... >>>>>> >>>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>>> /usr/lib/libSolarisSerialParallel.so: >>>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>>> little-endian (Possible cause: endianness mismatch) >>>>>> Caught java.lang.UnsatisfiedLinkError: >>>>>> >>>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>>> >>>>>> while loading driver com.sun.comm.SolarisDriver >>>>>> >>>>>> Is there a way around this error? >>>>>> >>>>>> >>>>>> >>>>> What host OS are you running? From your original post it looks like 32 >>>>> bit Linux. >>>>> >>>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>>> depending on the underlying hardware architecture as well. >>>>> >>>>> >>>>> >>>>> >>>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>>> >>>> >>>> >>> I don't think Sun did binary libraries for Linux in the 2.0 version. >>> Can someone with more historical experience than I confirm that? >>> >>> I recently tried to port a Comm API application from Solaris sparc to >>> Linux x86 and likewise could not get my hands on the binary libraries. >>> I eventually just re-wrote the code to use the gnu namespace packages >>> and rxtx 2.1. >>> >>> What I don't understand is why your application vendor does not >>> provide everything you need to run their software. >>> >>> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >>> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >>> /usr/java/default which is actually a softlink to >>> /usr/java/jre1.6.0_05. >>> >>> >>> >> Jeff, >> >> I would like for my vendor to switch to rxtx 2.1. It would make things much >> easier for me. I'm not sure why he's still using the javax compatible code. >> He's a small operation. Re-writing the code to use gnu namespace sounds like >> a major overhaul. Was it? >> > > I found it quite easy. In fact, in order to accommodate the > transition, I actually separated all of the code that deals directly > with the Comm API or RXTX into a helper class. The helper class was > then coded to use reflection to determine which library was available > and then instantiate the necessary objects. No direct imports of > either library are used. The main application just needs to get it's > hands on the IO streams and need not deal directly with the libraries. > Other programs may not be so simple... > > But this doesn't really help you unless your vendor forks over the > source code... > > Jeff, This may not help me directly, but I'm going to forward this thread to the vendor. I think he'll be open to making things work. Thanks again, Rick Knight From agusmunioz at gmail.com Thu Aug 7 16:39:51 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Thu, 7 Aug 2008 19:39:51 -0300 Subject: [Rxtx] How to send ack? Message-ID: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Hi, I'm still learning about serial communication and I have some doubts. I've got this question about how to do the following thing in rxtx. I have this hardware that connect to a PC using a serial port. These hardware receives data from a telephone line, proccess it, and then send it forward to the serial port. I've used a program named wincomm that shows what information is send it through the serial port and I have the nex behaviour: The hardware has a buffer where all data is stored, that cannot be sent it through the seria port. The program reads the first data send it by the hardware, and keep reading the same data always. There is a button in the application that says enable Ack, and when I click, then the hardware start to send all the stored information, and all the information is shown. I write a class, using rxtx that reads the serial port, and the same thing happens, it remains reading the same (first) data all the time. And I thing something like the enable Ack I'm missing. How can I do this enable Ack from my java code using rxtx? Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080807/e0a0f9a1/attachment-0020.html From ajmas at sympatico.ca Thu Aug 7 18:26:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 7 Aug 2008 20:26:41 -0400 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: <4BF42297-81E2-4BB8-A89F-1D43588379AE@sympatico.ca> On 6-Aug-08, at 19:40 , Bruce Boyes wrote: >> Unless I have missed the documentation for RXTX? I javadocced the >> RXTX >> source but information (to me) is minimal. >> Somewhere I got the impression that the Sun Comm API docs is, or was, >> compatible with RXTX, what is the best docs to use in conjuntion >> with RXTX >> and where may the be available? > > Yeah, this is one of my concerns/beefs. There is little documentation > for RXTX and it isn't just the same as javaxcomm. > > I would be willing to help out writing docs for RXTX! Yes really... > esp if we can fix the Bluetooth issues. If you want to contribute documentation then the best place to do that is the wiki. If there is anything missing or that could be improved on then please do so. If there are any points that you would like to see improved, for which you don't have the knowledge then ask on the mailing list for a volunteer. Andre From florianmanschwetus at gmx.de Fri Aug 8 03:04:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Fri, 08 Aug 2008 11:04:14 +0200 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Message-ID: <489C0C0E.2020401@gmx.de> Agustin Mu?oz schrieb: > Hi, I'm still learning about serial communication and I have some > doubts. I've got this question about how to do the following thing in rxtx. > I have this hardware that connect to a PC using a serial port. These > hardware receives data from a telephone line, proccess it, and then send > it forward to the serial port. I've used a program named wincomm that > shows what information is send it through the serial port and I have the > nex behaviour: > > The hardware has a buffer where all data is stored, that cannot be sent > it through the seria port. > The program reads the first data send it by the hardware, and keep > reading the same data always. > There is a button in the application that says enable Ack, and when I > click, then the hardware start to send all the stored information, and > all the information is shown. > > I write a class, using rxtx that reads the serial port, and the same > thing happens, it remains reading the same (first) data all the time. > And I thing something like the enable Ack I'm missing. > How can I do this enable Ack from my java code using rxtx? Afaik, a look at man ascii reveals: Okt Dez Hex Char 006 6 06 ACK So, i hope this will do the job: send(6); florian > > Thanks in advance > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/5b4965f8/attachment-0020.bin From agusmunioz at gmail.com Fri Aug 8 16:31:00 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 19:31:00 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <489C0C0E.2020401@gmx.de> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> Message-ID: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Hi Florian, thanks for the answer. By send(6) you mean to get the port OutputStream and write a 6? I try that but it didn't work. Any suggestion? Thanks On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < florianmanschwetus at gmx.de> wrote: > Agustin Mu?oz schrieb: > > Hi, I'm still learning about serial communication and I have some doubts. >> I've got this question about how to do the following thing in rxtx. >> I have this hardware that connect to a PC using a serial port. These >> hardware receives data from a telephone line, proccess it, and then send it >> forward to the serial port. I've used a program named wincomm that shows >> what information is send it through the serial port and I have the nex >> behaviour: >> >> The hardware has a buffer where all data is stored, that cannot be sent >> it through the seria port. >> The program reads the first data send it by the hardware, and keep reading >> the same data always. >> There is a button in the application that says enable Ack, and when I >> click, then the hardware start to send all the stored information, and all >> the information is shown. >> >> I write a class, using rxtx that reads the serial port, and the same thing >> happens, it remains reading the same (first) data all the time. And I thing >> something like the enable Ack I'm missing. >> How can I do this enable Ack from my java code using rxtx? >> > Afaik, a look at man ascii reveals: > Okt Dez Hex Char > 006 6 06 ACK > So, i hope this will do the job: > send(6); > > florian > >> >> Thanks in advance >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/7f3fba42/attachment-0019.html From agusmunioz at gmail.com Fri Aug 8 18:39:27 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 21:39:27 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Message-ID: <988288430808081739x7f9e7889id82591d5a9e2b4f6@mail.gmail.com> Ok, Florian, it works!! my problem was that I've been sending, through the OutputStream, the bytes of 6 as a string: out.write("6".getBytes()); but then I realized that you can write an int on an OuptuStream, so I tried that and It works: out.write(6); Thank you for the guidance!! On Fri, Aug 8, 2008 at 7:31 PM, Agustin Mu?oz wrote: > Hi Florian, thanks for the answer. By send(6) you mean to get the port > OutputStream and write a 6? > > I try that but it didn't work. > > Any suggestion? > > Thanks > > > On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < > florianmanschwetus at gmx.de> wrote: > >> Agustin Mu?oz schrieb: >> >> Hi, I'm still learning about serial communication and I have some doubts. >>> I've got this question about how to do the following thing in rxtx. >>> I have this hardware that connect to a PC using a serial port. These >>> hardware receives data from a telephone line, proccess it, and then send it >>> forward to the serial port. I've used a program named wincomm that shows >>> what information is send it through the serial port and I have the nex >>> behaviour: >>> >>> The hardware has a buffer where all data is stored, that cannot be sent >>> it through the seria port. >>> The program reads the first data send it by the hardware, and keep >>> reading the same data always. >>> There is a button in the application that says enable Ack, and when I >>> click, then the hardware start to send all the stored information, and all >>> the information is shown. >>> >>> I write a class, using rxtx that reads the serial port, and the same >>> thing happens, it remains reading the same (first) data all the time. And I >>> thing something like the enable Ack I'm missing. >>> How can I do this enable Ack from my java code using rxtx? >>> >> Afaik, a look at man ascii reveals: >> Okt Dez Hex Char >> 006 6 06 ACK >> So, i hope this will do the job: >> send(6); >> >> florian >> >>> >>> Thanks in advance >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/b918ab3d/attachment-0019.html From florianmanschwetus at gmx.de Sat Aug 9 00:45:43 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Sat, 09 Aug 2008 08:45:43 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4899667C.6010706@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> Message-ID: <489D3D17.9090209@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >> Florian Manschwetus wrote: >>> Ok, sounds fine for the receiving problem. >>> But why i have to wait after each byte when sending a command squence? >>> (the for loop in send command) >> >> Hi Florian, >> I'd imagine you probably don't! You could send all bytes in one go and >> RXTX would send them. The problem is most probably the other end: >> perhaps it has a really small buffer, some non-standard UART, or a >> crazy timing issue. If you attach a terminal to your output and send >> all the bytes of a command in one go they should appear no problem. >> >> Regards, >> Michael Erskine. >> > correct with a terminal on the other end it works, my idea was that this > basic baud has some influence. Could some one explain what it is for? > > Florian To make it more clear, my problem is that i can't use: outputStream.write(byte[]); => Beamer doesn't understand the sequence. (mostly no answer when he answers then *001) when i use this construct instead: for (int i = 0; i < command.length; i++) { this.outputStream.write(command[i]); try { Thread.sleep(25); } catch (InterruptedException e) { // TODO Auto-generated catch block e.printStackTrace(); } } it works nearly reliable. So what could it be? This Basic Baud is what exactly? Florian -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080809/692304ee/attachment-0019.bin From tjarvi at qbang.org Sat Aug 9 16:37:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Aug 2008 16:37:19 -0600 (MDT) Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489D3D17.9090209@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> <489D3D17.9090209@gmx.de> Message-ID: On Sat, 9 Aug 2008, Florian Manschwetus wrote: > Florian Manschwetus schrieb: >> Michael Erskine schrieb: >>> Florian Manschwetus wrote: >>>> Ok, sounds fine for the receiving problem. >>>> But why i have to wait after each byte when sending a command squence? >>>> (the for loop in send command) >>> >>> Hi Florian, >>> I'd imagine you probably don't! You could send all bytes in one go and >>> RXTX would send them. The problem is most probably the other end: perhaps >>> it has a really small buffer, some non-standard UART, or a crazy timing >>> issue. If you attach a terminal to your output and send all the bytes of a >>> command in one go they should appear no problem. >>> >>> Regards, >>> Michael Erskine. >>> >> correct with a terminal on the other end it works, my idea was that this >> basic baud has some influence. Could some one explain what it is for? >> >> Florian > To make it more clear, > my problem is that i can't use: > outputStream.write(byte[]); > => Beamer doesn't understand the sequence. (mostly no answer when he answers > then *001) > > when i use this construct instead: > > for (int i = 0; i < command.length; i++) { > this.outputStream.write(command[i]); > try { > Thread.sleep(25); > } catch (InterruptedException e) { > // TODO Auto-generated catch block > e.printStackTrace(); > } > } > > it works nearly reliable. > > So what could it be? This Basic Baud is what exactly? > I suspect you are using the 'moon protocol' and don't know it. RXTX enables this by default. The buffer on the other end is first in first out while reading. If the buffer is full, the bits are hand carried to the moon and burried. Then if the other side reads a couple bytes, two more bytes go into the buffer followed by more moon protocol. The resulting array of bytes the other side reads may appear to be scrambled until you go to the moon, get the bits and insert them in the right place. Flow control can prevent the default moon protocol and throttles the communiation by almost writing a byte at a time as need be. Hardware flow control is preferable but software flow control should also work. Read and write can appear to hang if the other side is not connected. This is why we don't enable them all the time. If you can't use flow control, you have to take care with the moon protocol and give the other side time to read. That is what your slower version of write is doing. -- Trent Jarvi tjarvi at qbang.org From rxtx at allenjb.me.uk Mon Aug 11 08:06:36 2008 From: rxtx at allenjb.me.uk (AllenJB) Date: Mon, 11 Aug 2008 15:06:36 +0100 Subject: [Rxtx] Disabling EV_RXFLAG Message-ID: <48A0476C.2090800@allenjb.me.uk> Hi all, I'm working with a device which does not use an EvtChar and need to disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an event mask of FD 01 00 00. The reference software I have uses FB 00 00 00. With the rxtx mask I get framing errors which I believe are caused when the EvtChar is received. Is there currently a way with rxtx (I've using rxtx from Java) to disable EV_RXFLAG? If not from Java, where would I start if I wanted to turn the EV_RXFLAG option off in the C code? I've had a grep of the rxtx source code, but I can't see where EV_RXFLAG is being set. Thanks in advance, AllenJB From tjarvi at qbang.org Mon Aug 11 14:17:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Aug 2008 14:17:27 -0600 (MDT) Subject: [Rxtx] Disabling EV_RXFLAG In-Reply-To: <48A0476C.2090800@allenjb.me.uk> References: <48A0476C.2090800@allenjb.me.uk> Message-ID: On Mon, 11 Aug 2008, AllenJB wrote: > Hi all, > > I'm working with a device which does not use an EvtChar and need to > disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an > event mask of FD 01 00 00. The reference software I have uses FB 00 00 > 00. With the rxtx mask I get framing errors which I believe are caused > when the EvtChar is received. > > Is there currently a way with rxtx (I've using rxtx from Java) to > disable EV_RXFLAG? > > If not from Java, where would I start if I wanted to turn the EV_RXFLAG > option off in the C code? I've had a grep of the rxtx source code, but I > can't see where EV_RXFLAG is being set. > > Thanks in advance, > > AllenJB Hi Allen, I'd look at termios.c::tcsetattr() and termios.c::FillDCB() -- Trent Jarvi tjarvi at qbang.org From superdadusa at gmail.com Tue Aug 12 13:57:32 2008 From: superdadusa at gmail.com (John Choi) Date: Tue, 12 Aug 2008 13:57:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. Message-ID: Hi all, Just let you all know I just start to learn Java. I have download the serial comm package and the source code from open source communities.. I was able to verify with the given message string via serial monitor. when the given message string sends to the serial port then the character return added to the end of string by default if I use "Hello World" however if I changed to something else other than "Hello, World" there is no character return add to the end of string. I thing the library download from rxtx.org has implemented for the special strings. I can do like "login\n" in the string message to make character return but I don't want to add this individual custom character for each command return in every static message string I send, Can any who have done this might help me? Basically, something like this,, Write and add function to the program write a command, Reads the respond from a serial device.. Function handles multiple messages, Write: "com open" Read: Welcome to my world" expected Write: "admin" Read: Password?, expected Write: "admin" Read: you are successfully login terminal, expected. And I need to add a separate function handler handles a character return add to the each command above. If anyone can help this I can do the reset? Thank you in advance, John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0015.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SerialIO.java Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0015.pl From Steffen.DETTMER at ingenico.com Wed Aug 13 02:16:38 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 13 Aug 2008 10:16:38 +0200 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: References: Message-ID: <20080813081638.GA25412@elberon.bln.de.ingenico.com> * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > I can do like "login\n" in the string message to make character > return but I don't want to add this individual custom character > for each command return in every static message string I send, and why not?! > Can any who have done this might help me? what's about with writing a small wrapper function adding the carriage return? However, this would be slow, because either you call write two times (very bad) or the string needs to be copied, \n appended and written (since you are using Java Performance probably isn't so critical). Personally I would write `"login\n"' and `username + "\n"' etc., because since it is part of the command it should be part of the command definition string. > Basically, something like this,, Write and add function to the program write > a command, Reads the respond from a serial device.. correctly reading a `line' is more difficult. If you cannot make assumptions about timeouts and/or you need to have low delay, you need to read byte wise. If you need to save CPU resources you might need to add some buffering layer that you can read byte-wise but that is reading blockwise with some small timeout (lets say for serial lines something around byte transmission time times three or so). > /* > * To change this template, choose Tools | Templates > * and open the template in the editor. > */ :) > package joliba; > > /** > * > * @author root > */ :) > // derived from SUN's examples in the javax.comm package > import java.io.*; > import java.util.*; > //import javax.comm.*; // for SUN's serial/parallel port libraries > import gnu.io.*; // for rxtxSerial library > > public class SerialIO implements Runnable, SerialPortEventListener { > static CommPortIdentifier portId; > static CommPortIdentifier saveportId; > static Enumeration portList; > InputStream inputStream; > SerialPort serialPort; > Thread readThread; You need a thread for your synchronous RPC-style protocol? > static String messageString = "Hello, world!"; > static OutputStream outputStream; > static boolean outputBufferEmptyFlag = false; > > public static void main(String[] args) { > boolean portFound = false; > String defaultPort; > > // determine the name of the serial port on several operating systems > String osname = System.getProperty("os.name","").toLowerCase(); > if ( osname.startsWith("windows") ) { > // windows > defaultPort = "COM1"; > } else if (osname.startsWith("linux")) { > // linux > defaultPort = "/dev/ttyS0"; > } else if ( osname.startsWith("mac") ) { > // mac > defaultPort = "????"; > } else { > System.out.println("Sorry, your operating system is not supported"); > return; > } Is such a construction recommended? Isn't there some abstraction (like COM1 working on any platform)? [...] > try { > // activate the OUTPUT_BUFFER_EMPTY notifier > serialPort.notifyOnOutputEmpty(true); > } catch (Exception e) { > System.out.println("Error setting event notification"); > System.out.println(e.toString()); > System.exit(-1); > } I doubt that -1 is defined, probably some 127 or so would be the result, maybe better simply `throw e'? > public void writetoport() { > System.out.println("Writing \""+messageString+"\" to "+serialPort.getName()); > try { > // write string to serial port > outputStream.write(messageString.getBytes()); > } catch (IOException e) {} > } maybe something like /** * Writes the given output string and an additional carriage * return to the current outputStream. */ public void writeStringToPort( /** The output string (without CR). */ String output ) throws IOException { String outputLine = output + "\n"; outputStream.write(outputLine.getBytes()); } ? > > public SerialIO() { > // initalize serial port > try { > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > } catch (PortInUseException e) {} if the port is in use, you continue? Wonder that this works in Java, I would assume serialPort beeing uninitialized which AFAIK is an error in Java. > try { > inputStream = serialPort.getInputStream(); > } catch (IOException e) {} > > try { > serialPort.addEventListener(this); > } catch (TooManyListenersException e) {} > > // activate the DATA_AVAILABLE notifier > serialPort.notifyOnDataAvailable(true); > > try { > // set port parameters > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > } catch (UnsupportedCommOperationException e) {} > > // start the read thread > readThread = new Thread(this); > readThread.start(); > > } I think in all those exception cases you can abort, because it is unlikely that ignoring those errors allow a successful continuation, so in this case maybe it would be better to add a throw clause to the method. > public void run() { > // first thing in the thread, we initialize the write operation > initwritetoport(); > try { > while (true) { > // write string to port, the serialEvent will read it > writetoport(); > Thread.sleep(1000); > } > } catch (InterruptedException e) {} > } Does this make sense? Your `SimpleReadApp' writes one and the same string each second? > public void serialEvent(SerialPortEvent event) { > switch (event.getEventType()) { > case SerialPortEvent.BI: > case SerialPortEvent.OE: > case SerialPortEvent.FE: > case SerialPortEvent.PE: > case SerialPortEvent.CD: > case SerialPortEvent.CTS: > case SerialPortEvent.DSR: > case SerialPortEvent.RI: > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > break; > case SerialPortEvent.DATA_AVAILABLE: > // we get here if data has been received > byte[] readBuffer = new byte[20]; > try { > // read data > while (inputStream.available() > 0) { > int numBytes = inputStream.read(readBuffer); > } > // print data > String result = new String(readBuffer); > System.out.println("Read: "+result); > } catch (IOException e) {} I doubt that this is correct. I would assume you will get a 20 bytes result always, if more bytes would be available they would be printed in a second line but if less bytes are read I'd assume that the buffer/result contains zero bytes from implicite readBuffer contents initialisation (zero is no string terminator in Java AFAIK). > break; > } > } > } oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From florianmanschwetus at gmx.de Wed Aug 13 06:09:31 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 13 Aug 2008 14:09:31 +0200 Subject: [Rxtx] someone has seen such errors? Message-ID: <48A2CEFB.90007@gmx.de> I mean my communication mostly works, but it is far from perfect could this be the reason? Florian Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/949b9947/attachment-0015.bin From superdadusa at gmail.com Wed Aug 13 08:40:32 2008 From: superdadusa at gmail.com (John Choi) Date: Wed, 13 Aug 2008 08:40:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: <20080813081638.GA25412@elberon.bln.de.ingenico.com> References: <20080813081638.GA25412@elberon.bln.de.ingenico.com> Message-ID: Thank you so much Steffen and I will try that suggestion. John On 8/13/08, Steffen DETTMER wrote: > > * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > > I can do like "login\n" in the string message to make character > > return but I don't want to add this individual custom character > > for each command return in every static message string I send, > > and why not?! > > > Can any who have done this might help me? > > what's about with writing a small wrapper function adding the > carriage return? > However, this would be slow, because either you call write two > times (very bad) or the string needs to be copied, \n appended > and written (since you are using Java Performance probably isn't > so critical). > > Personally I would write `"login\n"' and `username + "\n"' etc., > because since it is part of the command it should be part of the > command definition string. > > > Basically, something like this,, Write and add function to the program > write > > a command, Reads the respond from a serial device.. > > correctly reading a `line' is more difficult. If you cannot make > assumptions about timeouts and/or you need to have low delay, you > need to read byte wise. If you need to save CPU resources you > might need to add some buffering layer that you can read > byte-wise but that is reading blockwise with some small timeout > (lets say for serial lines something around byte transmission > time times three or so). > > > /* > > * To change this template, choose Tools | Templates > > * and open the template in the editor. > > */ > > :) > > > package joliba; > > > > /** > > * > > * @author root > > */ > > :) > > > // derived from SUN's examples in the javax.comm package > > import java.io.*; > > import java.util.*; > > //import javax.comm.*; // for SUN's serial/parallel port libraries > > import gnu.io.*; // for rxtxSerial library > > > > public class SerialIO implements Runnable, SerialPortEventListener { > > static CommPortIdentifier portId; > > static CommPortIdentifier saveportId; > > static Enumeration portList; > > InputStream inputStream; > > SerialPort serialPort; > > Thread readThread; > > You need a thread for your synchronous RPC-style protocol? > > > static String messageString = "Hello, world!"; > > static OutputStream outputStream; > > static boolean outputBufferEmptyFlag = false; > > > > public static void main(String[] args) { > > boolean portFound = false; > > String defaultPort; > > > > // determine the name of the serial port on several operating > systems > > String osname = System.getProperty("os.name","").toLowerCase(); > > if ( osname.startsWith("windows") ) { > > // windows > > defaultPort = "COM1"; > > } else if (osname.startsWith("linux")) { > > // linux > > defaultPort = "/dev/ttyS0"; > > } else if ( osname.startsWith("mac") ) { > > // mac > > defaultPort = "????"; > > } else { > > System.out.println("Sorry, your operating system is not > supported"); > > return; > > } > > Is such a construction recommended? Isn't there some abstraction > (like COM1 working on any platform)? > > [...] > > try { > > // activate the OUTPUT_BUFFER_EMPTY notifier > > serialPort.notifyOnOutputEmpty(true); > > } catch (Exception e) { > > System.out.println("Error setting event notification"); > > System.out.println(e.toString()); > > System.exit(-1); > > } > > I doubt that -1 is defined, probably some 127 or so would be the > result, maybe better simply `throw e'? > > > public void writetoport() { > > System.out.println("Writing \""+messageString+"\" to > "+serialPort.getName()); > > try { > > // write string to serial port > > outputStream.write(messageString.getBytes()); > > } catch (IOException e) {} > > } > > maybe something like > > /** > * Writes the given output string and an additional carriage > * return to the current outputStream. > */ > public void > writeStringToPort( > /** The output string (without CR). */ > String output > ) throws IOException > { > String outputLine = output + "\n"; > outputStream.write(outputLine.getBytes()); > } > > ? > > > > > public SerialIO() { > > // initalize serial port > > try { > > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > > } catch (PortInUseException e) {} > > if the port is in use, you continue? Wonder that this works in > Java, I would assume serialPort beeing uninitialized which AFAIK > is an error in Java. > > > try { > > inputStream = serialPort.getInputStream(); > > } catch (IOException e) {} > > > > try { > > serialPort.addEventListener(this); > > } catch (TooManyListenersException e) {} > > > > // activate the DATA_AVAILABLE notifier > > serialPort.notifyOnDataAvailable(true); > > > > try { > > // set port parameters > > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > } catch (UnsupportedCommOperationException e) {} > > > > // start the read thread > > readThread = new Thread(this); > > readThread.start(); > > > > } > > I think in all those exception cases you can abort, because it is > unlikely that ignoring those errors allow a successful > continuation, so in this case maybe it would be better to add a > throw clause to the method. > > > public void run() { > > // first thing in the thread, we initialize the write operation > > initwritetoport(); > > try { > > while (true) { > > // write string to port, the serialEvent will read it > > writetoport(); > > Thread.sleep(1000); > > } > > } catch (InterruptedException e) {} > > } > > Does this make sense? Your `SimpleReadApp' writes one and the > same string each second? > > > public void serialEvent(SerialPortEvent event) { > > switch (event.getEventType()) { > > case SerialPortEvent.BI: > > case SerialPortEvent.OE: > > case SerialPortEvent.FE: > > case SerialPortEvent.PE: > > case SerialPortEvent.CD: > > case SerialPortEvent.CTS: > > case SerialPortEvent.DSR: > > case SerialPortEvent.RI: > > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > > break; > > case SerialPortEvent.DATA_AVAILABLE: > > // we get here if data has been received > > byte[] readBuffer = new byte[20]; > > try { > > // read data > > while (inputStream.available() > 0) { > > int numBytes = inputStream.read(readBuffer); > > } > > // print data > > String result = new String(readBuffer); > > System.out.println("Read: "+result); > > } catch (IOException e) {} > > I doubt that this is correct. I would assume you will get a 20 > bytes result always, if more bytes would be available they would > be printed in a second line but if less bytes are read I'd assume > that the buffer/result contains zero bytes from implicite > readBuffer contents initialisation (zero is no string terminator > in Java AFAIK). > > > break; > > } > > } > > } > > oki, > > Steffen > > About Ingenico Throughout the world businesses rely on Ingenico for secure > and expedient electronic transaction acceptance. Ingenico products leverage > proven technology, established standards and unparalleled ergonomics to > provide optimal reliability, versatility and usability. This comprehensive > range of products is complemented by a global array of services and > partnerships, enabling businesses in a number of vertical sectors to accept > transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged > information. If you are not the addressee or authorized to receive this for > the addressee, you must not use, copy, disclose or take any action based on > this message or any information herein. If you have received this message in > error, please advise the sender immediately by reply e-mail and delete this > message. Thank you for your cooperation. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/73c4135c/attachment-0014.html From ajmas at sympatico.ca Sat Aug 16 07:15:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 09:15:41 -0400 Subject: [Rxtx] someone has seen such errors? In-Reply-To: <48A2CEFB.90007@gmx.de> References: <48A2CEFB.90007@gmx.de> Message-ID: <43B5E8DA-1D93-4D90-809B-AAF35FF724C5@sympatico.ca> On 13-Aug-08, at 08:09 , Florian Manschwetus wrote: > I mean my communication mostly works, but it is far from perfect > could this be the reason? > > Florian > > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control Judging by the error messages this looks related to the driver you are using. Do a search for the following string with you favourite search engine, it should turn up a few hits: ftdi_set_termios FAILED to set databits/stopbits/parity Andre From ajmas at sympatico.ca Sat Aug 16 19:12:04 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 21:12:04 -0400 Subject: [Rxtx] Using SerialPortEvent? Message-ID: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Hi, Could someone tell me how I should be using the SerialPortEvent? Am I meant to be waiting for data and then simply reading from the inputstream? If this is the case why no just block on an inputstream read? Andr? From tjarvi at qbang.org Sat Aug 16 19:41:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 16 Aug 2008 19:41:13 -0600 (MDT) Subject: [Rxtx] Using SerialPortEvent? In-Reply-To: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> References: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Message-ID: On Sat, 16 Aug 2008, Andre-John Mas wrote: > Hi, > > Could someone tell me how I should be using the SerialPortEvent? Am I > meant to be waiting for data and then simply reading from the > inputstream? If this is the case why no just block on an inputstream > read? > Polling for data is fine also. It really depends upon what you are trying to do. For instance, if you require x bytes before reading, you can start polling after data is available. If you read on the same thread as your GUI and are waiting for data in a read, the results may be less than desirable. Java programming is 'usually' event driven rather than polling based. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sat Aug 16 20:10:39 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 22:10:39 -0400 Subject: [Rxtx] Using SerialPortEvent? In-Reply-To: References: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Message-ID: <3E495D4C-BB28-4845-A6AB-984C9A826BDF@sympatico.ca> On 16-Aug-08, at 21:41 , Trent Jarvi wrote: > On Sat, 16 Aug 2008, Andre-John Mas wrote: > >> Hi, >> >> Could someone tell me how I should be using the SerialPortEvent? Am I >> meant to be waiting for data and then simply reading from the >> inputstream? If this is the case why no just block on an inputstream >> read? >> > > Polling for data is fine also. It really depends upon what you are > trying to do. For instance, if you require x bytes before reading, > you can start polling after data is available. If you read on the > same thread as your GUI and are waiting for data in a read, the > results may be less than desirable. > > Java programming is 'usually' event driven rather than polling based. Sounds good. I thought I would use this opportunity to provide a event based version of the TwoWaySerialComm example. Could you just validate it before I add it to the Wiki: package ajmas74.experimental; import gnu.io.CommPort; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; import gnu.io.SerialPortEvent; import gnu.io.SerialPortEventListener; import java.io.IOException; import java.io.InputStream; import java.io.OutputStream; /** * This version of the TwoWaySerialComm example makes use of the * SerialPortEventListener to avoid polling. * * @author ajmas * */ public class TwoWaySerialComm { public TwoWaySerialComm() { super(); } void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { CommPort commPort = portIdentifier.open(this.getClass().getName(),2000); if ( commPort instanceof SerialPort ) { SerialPort serialPort = (SerialPort) commPort; serialPort .setSerialPortParams (57600 ,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); (new Thread(new SerialWriter(out))).start(); serialPort.addEventListener(new SerialReader(in)); } else { System.out.println("Error: Only serial ports are handled by this example."); } } } /** * Handles the input coming from the serial port. A new line character * is treated as the end of a block in this example. */ public static class SerialReader implements SerialPortEventListener { private InputStream in; private byte[] buffer = new byte[1024]; public SerialReader ( InputStream in ) { this.in = in; } public void serialEvent(SerialPortEvent arg0) { int data; try { int len = 0; while ( ( data = in.read()) > -1 ) { if ( data != '\n' ) { break; } buffer[len++] = (byte) data; } System.out.print(new String(buffer,0,len)); } catch ( IOException e ) { e.printStackTrace(); System.exit(-1); } } } /** */ public static class SerialWriter implements Runnable { OutputStream out; public SerialWriter ( OutputStream out ) { this.out = out; } public void run () { try { int c = 0; while ( ( c = System.in.read()) > -1 ) { this.out.write(c); } } catch ( IOException e ) { e.printStackTrace(); System.exit(-1); } } } public static void main ( String[] args ) { try { (new TwoWaySerialComm()).connect("COM3"); } catch ( Exception e ) { e.printStackTrace(); } } } From lfarkas at lfarkas.org Tue Aug 19 07:32:59 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Tue, 19 Aug 2008 15:32:59 +0200 Subject: [Rxtx] JNI or CNI Message-ID: <48AACB8B.9060606@lfarkas.org> hi, what is the current recommended way to rxtx on linux JNI or it's better to use CNI? is the CNI version fully functional and the same level as the JNI? i currently try to make a rhel/centos/fedora rpm for rxtx but has many problems with the standard dir structure. yours. -- Levente "Si vis pacem para bellum!" From lfarkas at lfarkas.org Tue Aug 19 08:47:34 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Tue, 19 Aug 2008 16:47:34 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel Message-ID: <48AADD06.7040809@lfarkas.org> hi, newer or not so newer linux kernel do not contain the UTS_RELEASE so the current rxtx is not compile on the latest kernels. even if it's commented out in the cvs configure there are other places. i attcahed a patch which fix it (or at least doesn't cause error at non-debug build). ps. is there any plan to the new 2.1-8 release in the near future? there are many changes (at least the license change in all file and in this case create a diff is very difficult)? the latest release more then 2 years old:-( -- Levente "Si vis pacem para bellum!" -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-2.1-uts.patch Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080819/ab5d38ac/attachment-0008.pl From ajmas at sympatico.ca Tue Aug 19 16:21:53 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 19 Aug 2008 18:21:53 -0400 Subject: [Rxtx] Event based example Message-ID: <24735BFB-B088-4B84-8173-FE98DF63B12F@sympatico.ca> Hi, I have just posted an example of using SerialPortEventListener in the Wiki: http://rxtx.qbang.org/wiki/index.php/Event_Based_Two_Way_Communication If you see any issues please could you let me know, or makes the changes. Andre From Martin.Oberhuber at windriver.com Fri Aug 22 04:02:24 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 22 Aug 2008 12:02:24 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <48AADD06.7040809@lfarkas.org> References: <48AADD06.7040809@lfarkas.org> Message-ID: <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> Farkas, there are indeed efforts to get a new RXTX release out the door. Your experience as a package maintainer would likely be helpful during these efforts, since I'd think it makes sense to keep the patches minimal that you must make to have the source compile in your environment. What are the things that you find problematic, apart from the UTS thing that you have mentioned before? What is the timing that you have in mind for your package? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Farkas Levente > Sent: Tuesday, August 19, 2008 4:48 PM > To: rxtx at qbang.org > Subject: [Rxtx] UTS_RELEASE not defined in newer kernel > > hi, > newer or not so newer linux kernel do not contain the > UTS_RELEASE so the > current rxtx is not compile on the latest kernels. even if it's > commented out in the cvs configure there are other places. > i attcahed a patch which fix it (or at least doesn't cause error at > non-debug build). > > ps. is there any plan to the new 2.1-8 release in the near > future? there > are many changes (at least the license change in all file and in this > case create a diff is very difficult)? the latest release more then 2 > years old:-( > > -- > Levente "Si vis pacem para bellum!" > From lfarkas at lfarkas.org Fri Aug 22 04:36:26 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Fri, 22 Aug 2008 12:36:26 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> References: <48AADD06.7040809@lfarkas.org> <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> Message-ID: <48AE96AA.6090505@lfarkas.org> hi, the packages already build for fedora-9 and centos-5 and here: http://www.lfarkas.org/linux/packages/ what i've to patch, the UTS, the configure script, but it's already fixed in the cvs (in another way) and the loadlibrary. the reasons for last one can be found here: https://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_files_that_use_JNI after we test it i'd like to add these packages to fedora and epel main repository (that's why it's be useful a new release after 2 years:-) imho versions are cheap and why not just release 2.1-8? the real code changes are minimal and if something critical bug found still can release 2.1-9:-) ps. and would be better to use simple number for version like 2.1-7 rather then 2.1-7v2. Oberhuber, Martin wrote: > Farkas, > > there are indeed efforts to get a new RXTX release out the > door. Your experience as a package maintainer would likely > be helpful during these efforts, since I'd think it makes > sense to keep the patches minimal that you must make to > have the source compile in your environment. > > What are the things that you find problematic, apart from > the UTS thing that you have mentioned before? > > What is the timing that you have in mind for your package? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >> On Behalf Of Farkas Levente >> Sent: Tuesday, August 19, 2008 4:48 PM >> To: rxtx at qbang.org >> Subject: [Rxtx] UTS_RELEASE not defined in newer kernel >> >> hi, >> newer or not so newer linux kernel do not contain the >> UTS_RELEASE so the >> current rxtx is not compile on the latest kernels. even if it's >> commented out in the cvs configure there are other places. >> i attcahed a patch which fix it (or at least doesn't cause error at >> non-debug build). >> >> ps. is there any plan to the new 2.1-8 release in the near >> future? there >> are many changes (at least the license change in all file and in this >> case create a diff is very difficult)? the latest release more then 2 >> years old:-( >> >> -- >> Levente "Si vis pacem para bellum!" >> -- Levente "Si vis pacem para bellum!" From tjarvi at qbang.org Fri Aug 22 18:50:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Aug 2008 18:50:32 -0600 (MDT) Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <48AE96AA.6090505@lfarkas.org> References: <48AADD06.7040809@lfarkas.org> <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> <48AE96AA.6090505@lfarkas.org> Message-ID: Hi Farkas, The v2 was simply the second build - no code changes. We are comming out with a new release shortly. I would encourage working with distros as you are. The building of rxtx turns out to be a bottle neck in quick releases. We do want stable releases that work for a year or more but I would have no problems with quicker cycles on developing work. I would have no problem working with someone that did builds that receive less testing more often but they do have to come out for multiple platforms from this end. Thanks for the links. On Fri, 22 Aug 2008, Farkas Levente wrote: > hi, > the packages already build for fedora-9 and centos-5 and here: > http://www.lfarkas.org/linux/packages/ > what i've to patch, the UTS, the configure script, but it's already > fixed in the cvs (in another way) and the loadlibrary. the reasons for > last one can be found here: > https://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_files_that_use_JNI > after we test it i'd like to add these packages to fedora and epel main > repository (that's why it's be useful a new release after 2 years:-) > imho versions are cheap and why not just release 2.1-8? the real code > changes are minimal and if something critical bug found still can > release 2.1-9:-) > > ps. and would be better to use simple number for version like 2.1-7 > rather then 2.1-7v2. > > Oberhuber, Martin wrote: >> Farkas, >> >> there are indeed efforts to get a new RXTX release out the >> door. Your experience as a package maintainer would likely >> be helpful during these efforts, since I'd think it makes >> sense to keep the patches minimal that you must make to >> have the source compile in your environment. >> >> What are the things that you find problematic, apart from >> the UTS thing that you have mentioned before? >> >> What is the timing that you have in mind for your package? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >>> On Behalf Of Farkas Levente >>> Sent: Tuesday, August 19, 2008 4:48 PM >>> To: rxtx at qbang.org >>> Subject: [Rxtx] UTS_RELEASE not defined in newer kernel >>> >>> hi, >>> newer or not so newer linux kernel do not contain the >>> UTS_RELEASE so the >>> current rxtx is not compile on the latest kernels. even if it's >>> commented out in the cvs configure there are other places. >>> i attcahed a patch which fix it (or at least doesn't cause error at >>> non-debug build). >>> >>> ps. is there any plan to the new 2.1-8 release in the near >>> future? there >>> are many changes (at least the license change in all file and in this >>> case create a diff is very difficult)? the latest release more then 2 >>> years old:-( >>> >>> -- >>> Levente "Si vis pacem para bellum!" >>> > > > From andy at triera.net Sat Aug 23 15:17:44 2008 From: andy at triera.net (Andy Rozman) Date: Sat, 23 Aug 2008 21:17:44 +0000 Subject: [Rxtx] port not identified on FreeBSD In-Reply-To: References: Message-ID: <48B07E78.2030306@triera.net> Hi ! I have one small problem... I have started using FreeBSD in last few days and I have come accross a problem with rxtx on FreeBSD. I am using usb-to-serial converter, which is identified under FreeBSD without problem as ucom0, and creates link under /dev called ttyU0, which is correct way to be done under FreeBSD (if device would be unidentified it would be called ugen0 - as usb generic). Problem is that I say to rxtx to get my all serial ports this one is not among them. Which names are permissable under linux-like implementations? Which will be accepted as serial ports? Andy From tjarvi at qbang.org Sat Aug 23 13:57:45 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 23 Aug 2008 13:57:45 -0600 (MDT) Subject: [Rxtx] port not identified on FreeBSD In-Reply-To: <48B07E78.2030306@triera.net> References: <48B07E78.2030306@triera.net> Message-ID: On Sat, 23 Aug 2008, Andy Rozman wrote: > Hi ! > > I have one small problem... I have started using FreeBSD in last few > days and I have come accross a problem with rxtx on FreeBSD. > > I am using usb-to-serial converter, which is identified under FreeBSD > without problem as ucom0, and creates link under /dev called > ttyU0, which is correct way to be done under FreeBSD (if device would be > unidentified it would be called ugen0 - as usb generic). Problem is that > I say to rxtx to get my all serial ports this one is not among them. > Which names are permissable under linux-like implementations? Which will > be accepted as serial ports? > > Andy > Thanks Andy! We will add ttyU* to FreeBSD. For now you can use properties to enable the port. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting#How_does_rxtx_detect_ports.3F__Can_I_override_it.3F The fix: diff -u -r1.16.2.59 RXTXCommDriver.java --- RXTXCommDriver.java 18 Nov 2007 22:32:41 -0000 1.16.2.59 +++ RXTXCommDriver.java 23 Aug 2008 19:55:25 -0000 @@ -644,6 +644,7 @@ { String[] Temp = { "ttyd", //general purpose serial ports + "ttyU", //general purpose USB serial ports "cuaa", //dialout serial ports "ttyA", //Specialix SI/XIO dialin ports "cuaA", //Specialix SI/XIO dialout ports -- Trent Jarvi tjarvi at qbang.org From rick_knight at rlknight.com Mon Aug 4 13:25:10 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Mon, 04 Aug 2008 12:25:10 -0700 Subject: [Rxtx] Sun's Comm API? Message-ID: <48975796.4010600@rlknight.com> I have an application that requires the javax compatible version of RXTX and Sun's comm api. I've been able to download and extract the version of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api anywhere. Can someone tell me where I can find it? Or maybe send me a copy? Also, when I try to build RXTX, configure and make complete successfully but make install failes with this error libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 I've never come accross this error before. How can I get past it? Thanks, Rick From bboyes at systronix.com Mon Aug 4 19:10:01 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:10:01 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48975796.4010600@rlknight.com> References: <48975796.4010600@rlknight.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/cb9c6167/attachment-0024.html From bboyes at systronix.com Mon Aug 4 19:12:37 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:12:37 -0600 Subject: [Rxtx] Towards an RXTX release - CSR BT/USB chipset In-Reply-To: <488FB7E7.8000802@gmail.com> References: <460801A4097E3D4CA04CC64EE648584806C56CF0@ism-mail03.corp.ad.wrs.com> <13557-75390@sneakemail.com> <20980-23424@sneakemail.com> <488FB7E7.8000802@gmail.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/52236088/attachment-0024.html From tjarvi at qbang.org Mon Aug 4 19:42:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 19:42:21 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: On Mon, 4 Aug 2008, Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: > I have an application that requires the javax compatible > version of RXTX > and Sun's comm api. I've been able to download and extract > the version > of RXTX that I need (2.0-7pre2) but I can't find Sun's camm > api > anywhere. Can someone tell me where I can find it? Or maybe > send me a > > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm port > support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have just > a ZIP with only the .class JAR file - no source or docs), has a readme > with these comments: > > This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release.? The 2.0.3 release itself is > no longer distributed.? comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project.? The RxTx project (http://www.rxtx.org ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org) was opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support.? Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins.? Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > ? > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > I hope that is helpful! > It would be nice to work with Sun to resolve those longstanding issues. But it may not be practical unless the process goes as fast and painless as the grandfathering of commapi did. Another option may be the old kaffe extensions that moved to gnu classpathx. These don't have the native libraries but should provide the 2.0 interface and the javax.comm.properties mechansim for SPI. http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Mon Aug 4 20:23:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Mon, 04 Aug 2008 20:23:57 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4897B9BD.5070809@ergotech.com> Has there been any work/would it be possible, to layer a javacomm look-alike on top of the GNU code? The goal is not to move the javax code forward, but to emulate the "legacy" javax packages for people who still need this. Jim Trent Jarvi wrote: > On Mon, 4 Aug 2008, Bruce Boyes wrote: > >> At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible >> version of RXTX >> and Sun's comm api. I've been able to download and extract >> the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm >> api >> anywhere. Can someone tell me where I can find it? Or maybe >> send me a >> >> >> javaxcomm has had a sort of on-again off-again history. The windoze >> version has been languishing for years (literally) but there are newer >> versions for other OS's. >> >> We try to keep links on one of our help pages current: >> http://www.practicalembeddedjava.com/tools/javatools_list.html >> which gets you to here: >> http://java.sun.com/products/javacomm/ >> where it says in fact they no longer even support Windows and Mac: >> "Implementations of the API are currently available for Solaris SPARC, >> Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so >> someone could support it. But I guess that's part of the reason RXTX >> exists! >> >> So one of Sun's own products, SunSPOT, has to use RXTX to get comm port >> support. >> >> The version we use is 2.0 from 11/15/1998. I have posted it on our >> website, which is within the terms of the license agreement contained >> therein (as I understand it). >> >> The last version of javaxcomm for Windows, 2.0.3, (for which I have just >> a ZIP with only the .class JAR file - no source or docs), has a readme >> with these comments: >> >> This distribution contains the comm.jar file original part >> of the COMMAPI 2.0.3 release. The 2.0.3 release itself is >> no longer distributed. comm.jar, which contains the comm >> API java class files (eg. Sun's binary implementation of the >> interface classes), is being made available, unsupported, >> with no obligation to fix bugs, at the request of the RXTX >> project. The RxTx project (http://www.rxtx.org ), uses the >> comm.jar class files, but provides their own native library >> components to provide support for other platforms. >> >> The 2.0.3 comm.jar is being provided in this way because >> as of COMMAPI 3.x, the java binary implementation forked and >> became incompatible with the RxTx project's native code. >> Due to the lack of a clear business case, and to resource >> constraints, no additional resources are being >> provided to provide an alternative engineering solution >> at the time of writing. >> >> RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: >> >> Ultimately the COMMAPI would be better served if a Java >> Community Process JSR (http://www.jcp.org) was opened and >> the COMMAPI was rearchitected to provide a more pluggable >> framework to improve cross-platform support. Such an >> architecture would embody a better defined and better >> documented SPI interface, including a way for comm. ports >> to be revealed to the client application through the API >> via platform-aware plugins. Similarly, native code used >> to access comm port in general could be handled more >> flexibly using a plugin model, whereby on any platform, >> multiple native modules could be in use simultaneously. >> >> Since there are now various ways serial ports can be implemented >> and accessed, modular comm. port JNI native libraries would be >> of benefit insofar as removing the burden of over-generalization >> from any single native component, or inversely, by relieving the >> implicit constraint that comm. drivers be accessed only via a >> monolithic mechanism, such as the UNIX vnode interface. >> >> paul.klissner at sun.com >> 6/10/06 >> >> I hope that is helpful! >> > > It would be nice to work with Sun to resolve those longstanding issues. > But it may not be practical unless the process goes as fast and painless > as the grandfathering of commapi did. > > Another option may be the old kaffe extensions that moved to gnu > classpathx. These don't have the native libraries but should provide > the 2.0 interface and the javax.comm.properties mechansim for SPI. > > http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Mon Aug 4 21:09:15 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 21:09:15 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? Message-ID: Hi Jim, I will not step into the javax.comm namespace without Sun's explicite permission. I fully understand the pain point you are trying to address. In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm Linux) - which remains an integral part of rxtx. At the time it was a win for Sun and rxtx. The Sun commapi license is/was fairly clear that rxtx should not step into that namespace. It made sense as Sun was active in that space and rxtx may go into another namespace - it was an experiment in working with Sun. This may sound silly looking at something that happened almost 10 years ago. In a community of respect which Sun helped create, there is no question about what to do. I hope eventually Sun will step up and do a right thing too. I agree that this is hurting the API more than helping it. There are also questions about how to replace the API in the long term which includes HID support which isn't going well so far. Others that can't even look at Sun's javax.comm today and can look at Kaffe's contribution to classpathx can easily work around such restrictions. On Mon, 4 Aug 2008, Jim Redman wrote: > Has there been any work/would it be possible, to layer a javacomm > look-alike on top of the GNU code? > > The goal is not to move the javax code forward, but to emulate the > "legacy" javax packages for people who still need this. > > Jim > > Trent Jarvi wrote: >> >> It would be nice to work with Sun to resolve those longstanding issues. >> But it may not be practical unless the process goes as fast and painless >> as the grandfathering of commapi did. >> >> Another option may be the old kaffe extensions that moved to gnu >> classpathx. These don't have the native libraries but should provide >> the 2.0 interface and the javax.comm.properties mechansim for SPI. >> >> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From florianmanschwetus at gmx.de Tue Aug 5 05:04:46 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 13:04:46 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: References: <48971C1F.9020806@gmx.de> Message-ID: <489833CE.1040801@gmx.de> Just look at sendCommand in this method I have to place a Thread.sleep(20) after each byte send to get working. Even the event based receive doesn't work fine but this could be may stupidness. The specifikation document (it is on the last pages of the manual) for the beamer could be found on: http://www.optoma.co.uk/support.aspx Florian Manschwetus Trent Jarvi schrieb: > > Hi Florian > > Sorry for the top post in advance. I worry you may not see my answer > under all your code :) > > I have not received this email before. This is 500k of code which I > don't have time to read. I can spend about 5 min on each hobby email > and still get to work in the morning. I have a couple suggestions for > how to get an answer. > > First, cut out your comments and extra code so you can demonstrate the > question (I might even glance and see what is wrong then). Don't go for > a working final product. Isolate the problem using a simple program and > then ask with that as an example. If I did what you just did, I'd have > to post 3/4 of a million lines of code :) > > Second, join the rxtx mail-list and ask there. This will give you 100x > more eyes. I'll also read and try to follow. > > -- > taj > > > > On Mon, 4 Aug 2008, Florian Manschwetus wrote: > >> It could be that my university account is blocked by filters so >> resending from here. >> >> >> Topic is to control Optoma HD80 beamer using rs232 serial chat. >> This code is able to detect power state and switch the beamer on / off. >> connected is the beamer using a digitus usb 2.0 serial adapter with an >> FT232 USB-Serial adapter the systems architecture is amd64. >> >> Please take a look in the sendCommand routine i have to place theire >> those Thread.sleep to get it working. >> Now the question is this correct or is there a better way to get this >> working correctly? >> >> In the javadoc coming with the install i found this: >> setBaudBase >> >> public boolean setBaudBase(int BaudBase) >> throws UnsupportedCommOperationException, >> java.io.IOException >> >> Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 >> before using. >> >> could this explain the error? >> I attached my java source and the protocol description for the beamer >> (available on vendor website). >> >> thx, >> Florian Manschwetus >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: TestRS232.java Type: text/x-java Size: 9143 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0048.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0049.bin From michael.erskine at ketech.com Tue Aug 5 05:53:49 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Tue, 5 Aug 2008 12:53:49 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489833CE.1040801@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> > Just look at sendCommand in this method I have to place a > Thread.sleep(20) after each byte send to get working. Even the event > based receive doesn't work fine but this could be may stupidness. Hi Florian, Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. Regards, Michael Erskine. From florianmanschwetus at gmx.de Tue Aug 5 07:28:15 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:28:15 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> Message-ID: <4898556F.8000208@gmx.de> Michael Erskine schrieb: >> Just look at sendCommand in this method I have to place a >> Thread.sleep(20) after each byte send to get working. Even the event >> based receive doesn't work fine but this could be may stupidness. > > Hi Florian, > > Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. > > Regards, > Michael Erskine. > Ok, sounds fine for the receiving problem. But why i have to wait after each byte when sending a command squence? (the for loop in send command) Florian > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/284f350c/attachment-0023.bin From florianmanschwetus at gmx.de Tue Aug 5 07:44:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:44:14 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <4898592E.2020908@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >>> Just look at sendCommand in this method I have to place a >>> Thread.sleep(20) after each byte send to get working. Even the event >>> based receive doesn't work fine but this could be may stupidness. >> >> Hi Florian, >> >> Yes, naturally you'll have to wait for a response from the other end. >> Why not wait for notification from the event thread perhaps using a >> BlockingDeque rather than your LinkedList. Generally I >> try to decouple all input and output streams: in your case your >> application is operating synchronously like the "expect" program >> (http://expect.nist.gov/) so waits (or timeouts) will need to be >> factored in. >> >> Regards, >> Michael Erskine. >> > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) > > Florian Furthermore there is this basic baud with this confusing javadoc entry: public boolean setBaudBase(int BaudBase) throws UnsupportedCommOperationException, java.io.IOException Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 before using. maybe this could explain something Florian >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/006c7425/attachment-0023.bin From jredman at ergotech.com Tue Aug 5 09:13:36 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 05 Aug 2008 09:13:36 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: Message-ID: <48986E20.3060104@ergotech.com> Trent, So two issues: 1) Technically I'm still not sure how easy/practical a layer would be. The problems are always classes like listeners, and wrapping returns of gnu.io classes. I really see it as a "delegate" type of concept. Any thoughts or ideas of the practicality of this approach? The idea is not to modify RXTX. 2) Javax. The javax namespace does seem to be in widespread use outside of Sun (the same is true for the java namespace). The classpath extensions, or some other location, should be interested in a JavaComm implementation even if it does have dependencies on RXTX. Would you have any philosophical objection to an approach like that? Of course, I suspect it might be better if someone with that authority at Sun would admit that the javax namespace is already in the wild and that there is no problem with it being used within RXTX. Jim Trent Jarvi wrote: > Hi Jim, > > I will not step into the javax.comm namespace without Sun's explicite > permission. I fully understand the pain point you are trying to address. > > In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm > Linux) - which remains an integral part of rxtx. At the time it was a win for > Sun and rxtx. > > The Sun commapi license is/was fairly clear that rxtx should not step into that > namespace. It made sense as Sun was active in that space and rxtx may go into > another namespace - it was an experiment in working with Sun. > > This may sound silly looking at something that happened almost 10 years ago. > In a community of respect which Sun helped create, there is no question about > what to do. I hope eventually Sun will step up and do a right thing too. > > I agree that this is hurting the API more than helping it. There are also > questions about how to replace the API in the long term which includes HID > support which isn't going well so far. > > Others that can't even look at Sun's javax.comm today and can look at Kaffe's > contribution to classpathx can easily work around such restrictions. > > On Mon, 4 Aug 2008, Jim Redman wrote: > >> Has there been any work/would it be possible, to layer a javacomm >> look-alike on top of the GNU code? >> >> The goal is not to move the javax code forward, but to emulate the >> "legacy" javax packages for people who still need this. >> >> Jim >> >> Trent Jarvi wrote: >>> It would be nice to work with Sun to resolve those longstanding issues. >>> But it may not be practical unless the process goes as fast and painless >>> as the grandfathering of commapi did. >>> >>> Another option may be the old kaffe extensions that moved to gnu >>> classpathx. These don't have the native libraries but should provide >>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>> >>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From sandeep at genevasoftech.com Tue Aug 5 11:18:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Tue, 05 Aug 2008 22:48:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <48988B6C.5080409@genevasoftech.com> Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. *-- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/ad20f1cb/attachment-0023.html From Martin.Oberhuber at windriver.com Tue Aug 5 13:30:17 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Tue, 5 Aug 2008 21:30:17 +0200 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Sandeep, shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on Sol7 but I've successfully run it on Sol9 and Sol10. Or is your request really about a native 64bit variant? I'm afraid that then you're out of luck since I think that quite a bit of RXTX is not yet ready for 64 bit. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Sandeep Kumar K Sent: Tuesday, August 05, 2008 7:19 PM To: rxtx at qbang.org Subject: [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so for Solaris 9 Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. -- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/81b7f988/attachment-0023.html From tjarvi at qbang.org Tue Aug 5 22:38:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 22:38:34 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 5 Aug 2008, Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built > on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid that > then > you're out of luck since I think that quite a bit of RXTX is not yet > ready > for 64 bit. > While rxtx-2.1-7 probably has problems, The CVS code should be OK for 64 bit Solaris. If it isn't, let me know and I'll find which patch is missing. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Aug 5 23:13:00 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 23:13:00 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48986E20.3060104@ergotech.com> References: <48986E20.3060104@ergotech.com> Message-ID: On Tue, 5 Aug 2008, Jim Redman wrote: > Trent, > > So two issues: > > 1) Technically I'm still not sure how easy/practical a layer would be. The > problems are always classes like listeners, and wrapping returns of gnu.io > classes. I really see it as a "delegate" type of concept. Any thoughts or > ideas of the practicality of this approach? The idea is not to modify RXTX. I have not put too much thought into this. I assume you want what rxtx 2.0 provided to tie into javax.comm implementations. More classes could be added to rxtx 2.1-7 for SPI support. Maintaining rxtx-2.0 could also be handed to someone if they like. > > 2) Javax. The javax namespace does seem to be in widespread use outside of > Sun (the same is true for the java namespace). The classpath extensions, or > some other location, should be interested in a JavaComm implementation even > if it does have dependencies on RXTX. Would you have any philosophical > objection to an approach like that? > No problems. Classpathx would be a possible place to do it. I'd suggest thinking twice about what this involves in practical terms. You would be wanting to revive the 2.0 API while Sun is at 3.0 and grandfathering the JSR. This undermines the main reason (established api) for using the javax.comm namespace and does not leave such a project in a good position. The only win I see here is maintaining support for applications that can't migrate namespaces. Not that that isn't important. At some point it is going to be less work to just edit the bytecode :) Such a javax.comm effort would also be signing up new projects that decided to use the work up for concerns they probably will not understand or expect. That probably isn't a good path to facilitate for new projects at this time. We will put a good faith effort to work well with others but keep in mind the project has limited bandwidth for such efforts. > Of course, I suspect it might be better if someone with that authority at Sun > would admit that the javax namespace is already in the wild and that there is > no problem with it being used within RXTX. > > Jim > > Trent Jarvi wrote: >> Hi Jim, >> >> I will not step into the javax.comm namespace without Sun's explicite >> permission. I fully understand the pain point you are trying to address. >> >> In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java >> Comm Linux) - which remains an integral part of rxtx. At the time it was a >> win for Sun and rxtx. >> >> The Sun commapi license is/was fairly clear that rxtx should not step into >> that namespace. It made sense as Sun was active in that space and rxtx may >> go into another namespace - it was an experiment in working with Sun. >> >> This may sound silly looking at something that happened almost 10 years >> ago. In a community of respect which Sun helped create, there is no >> question about what to do. I hope eventually Sun will step up and do a >> right thing too. >> >> I agree that this is hurting the API more than helping it. There are also >> questions about how to replace the API in the long term which includes HID >> support which isn't going well so far. >> >> Others that can't even look at Sun's javax.comm today and can look at >> Kaffe's contribution to classpathx can easily work around such >> restrictions. >> >> On Mon, 4 Aug 2008, Jim Redman wrote: >> >>> Has there been any work/would it be possible, to layer a javacomm >>> look-alike on top of the GNU code? >>> >>> The goal is not to move the javax code forward, but to emulate the >>> "legacy" javax packages for people who still need this. >>> >>> Jim >>> >>> Trent Jarvi wrote: >>>> It would be nice to work with Sun to resolve those longstanding issues. >>>> But it may not be practical unless the process goes as fast and painless >>>> as the grandfathering of commapi did. >>>> >>>> Another option may be the old kaffe extensions that moved to gnu >>>> classpathx. These don't have the native libraries but should provide >>>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>>> >>>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From sandeep at genevasoftech.com Wed Aug 6 00:03:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Wed, 06 Aug 2008 11:33:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: <48993EB8.30107@genevasoftech.com> Thank you Mr. Martin for your suggestion. The native file which is given in rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am getting the following error . Any suggestions to solve this issue. I am using Solaris SPARC 64 bit machine. ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) thrown while loading gnu.io.RXTXCommDriver Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(Unknown Source) at java.lang.ClassLoader.loadLibrary(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) at com.ReadFromModem.main(ReadFromModem.java:84) * * *Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid > that then > you're out of luck since I think that quite a bit of RXTX is not yet ready > for 64 bit. > > Cheers, > -- > *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > ------------------------------------------------------------------------ > *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On > Behalf Of *Sandeep Kumar K > *Sent:* Tuesday, August 05, 2008 7:19 PM > *To:* rxtx at qbang.org > *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so > for Solaris 9 > > Hi, > > Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 > bit machine. The librxtxSerial.so given in website is for Solaris 8. > > *-- > > Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/1e920343/attachment-0023.html From tjarvi at qbang.org Wed Aug 6 00:21:42 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 00:21:42 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <48993EB8.30107@genevasoftech.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> <48993EB8.30107@genevasoftech.com> Message-ID: Hi Sandeep You may be out of luck unless you can compile the 2.1 src in CVS (requires gnu make and gcc). But you could try the ToyBox(R)(TM) which is a collection of WiLdLy untested cross compiled 2.1-7 binaries covering everything from the ibm z series to embeded arm/ppc. To give an idea how poorly these are tested, I don't even know if z series machines have a serial port. ftp://www.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Solaris They should at least match the binary types. Actually, I think if you use the rxtx jar from CVS with that file, it should 'work' as the fix for 64 bits was in java not the native code. You could just cd rxtx*/src; javac *.java then jar -cf RXTXcomm.jar `find -name \*.class` to create the hybrid which will complain about version information a bit. On Wed, 6 Aug 2008, Sandeep Kumar K wrote: > Thank you Mr. Martin for your suggestion. The native file which is given in > rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am > getting the following error . > Any suggestions to solve this issue. > I am using Solaris SPARC 64 bit machine. > > ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar > java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 > (Possible cause: architecture word > width mismatch) thrown while loading gnu.io.RXTXCommDriver > Exception in thread "main" java.lang.UnsatisfiedLinkError: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF > class: ELFCLASS64 (Possible cause: > architecture word width mismatch) > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(Unknown Source) > at java.lang.ClassLoader.loadLibrary(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > at com.ReadFromModem.main(ReadFromModem.java:84) > > * > * > > *Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > > > Oberhuber, Martin wrote: >> Sandeep, >> shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse >> variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on >> Sol7 but I've successfully run it on Sol9 and Sol10. >> Or is your request really about a native 64bit variant? I'm afraid that >> then >> you're out of luck since I think that quite a bit of RXTX is not yet ready >> for 64 bit. >> Cheers, >> -- >> *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> ------------------------------------------------------------------------ >> *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On >> Behalf Of *Sandeep Kumar K >> *Sent:* Tuesday, August 05, 2008 7:19 PM >> *To:* rxtx at qbang.org >> *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so >> for Solaris 9 >> >> Hi, >> >> Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 >> bit machine. The librxtxSerial.so given in website is for Solaris 8. >> >> *-- >> Thanks & Regards >> >> Sandeep Kumar K >> Sr. Software Engineer >> Geneva Software Technologies >> Whitefield, Bangalore >> Mob : 9880193454* >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> From michael.erskine at ketech.com Wed Aug 6 01:39:28 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 6 Aug 2008 08:39:28 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Florian Manschwetus wrote: > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) Hi Florian, I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. Regards, Michael Erskine. From florianmanschwetus at gmx.de Wed Aug 6 02:53:16 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 06 Aug 2008 10:53:16 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Message-ID: <4899667C.6010706@gmx.de> Michael Erskine schrieb: > Florian Manschwetus wrote: >> Ok, sounds fine for the receiving problem. >> But why i have to wait after each byte when sending a command squence? >> (the for loop in send command) > > Hi Florian, > I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. > > Regards, > Michael Erskine. > correct with a terminal on the other end it works, my idea was that this basic baud has some influence. Could some one explain what it is for? Florian > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/c2b4fa84/attachment-0023.bin From rick_knight at rlknight.com Wed Aug 6 13:01:07 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:01:07 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F4F3.3020707@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > I have an application (Readerware) that uses RXTX with Javax to access the serial port. This used to work fine under previous Linux' and Java, but something has changed, I assume with Java itself , that is causing the application to fail with a link error. The application is not able to find librxtxSerialParallel.so. RXTX supplies librxtxSerial.so and librxtxParallel.so, but not librxtxSerialParallel.so. Where can I get librxtxSerialParallel.so, or do I need it? Is something else causing the lib to not be found? Thanks, Rick Knight From rick_knight at rlknight.com Wed Aug 6 13:17:55 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:17:55 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F8E3.5060400@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Thanks for the reply. The developer of the app I'm trying to use (Readerware) has sent me a copy of the comm.api and I've copied the library (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar into the proper places. When I try to run the application, I get this error... Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: /usr/lib/libSolarisSerialParallel.so: /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not little-endian (Possible cause: endianness mismatch) Caught java.lang.UnsatisfiedLinkError: com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I while loading driver com.sun.comm.SolarisDriver Is there a way around this error? Thanks again, Rick Knight From jlar310 at gmail.com Wed Aug 6 13:37:42 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 14:37:42 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899F8E3.5060400@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > The developer of the app I'm trying to use (Readerware) has sent me a > copy of the comm.api and I've copied the library > (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar > into the proper places. When I try to run the application, I get this > error... > > Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: > /usr/lib/libSolarisSerialParallel.so: > /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not > little-endian (Possible cause: endianness mismatch) > Caught java.lang.UnsatisfiedLinkError: > com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I > > while loading driver com.sun.comm.SolarisDriver > > Is there a way around this error? What host OS are you running? From your original post it looks like 32 bit Linux. The libSolarisSerialParallel.so file is for Sun Solaris and will vary depending on the underlying hardware architecture as well. Sorry for the double post Rick, but I failed to send this to the list the first time... -- Jeff From rick_knight at rlknight.com Wed Aug 6 13:44:29 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:44:29 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: <4899FF1D.9030504@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > > >> The developer of the app I'm trying to use (Readerware) has sent me a >> copy of the comm.api and I've copied the library >> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >> into the proper places. When I try to run the application, I get this >> error... >> >> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >> /usr/lib/libSolarisSerialParallel.so: >> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >> little-endian (Possible cause: endianness mismatch) >> Caught java.lang.UnsatisfiedLinkError: >> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >> >> while loading driver com.sun.comm.SolarisDriver >> >> Is there a way around this error? >> > > What host OS are you running? From your original post it looks like 32 > bit Linux. > > The libSolarisSerialParallel.so file is for Sun Solaris and will vary > depending on the underlying hardware architecture as well. > > I'm running Kubuntu Linux (debian based). It's 32 bit. Rick Knight From jlar310 at gmail.com Wed Aug 6 15:33:23 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 16:33:23 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > I don't think Sun did binary libraries for Linux in the 2.0 version. Can someone with more historical experience than I confirm that? I recently tried to port a Comm API application from Solaris sparc to Linux x86 and likewise could not get my hands on the binary libraries. I eventually just re-wrote the code to use the gnu namespace packages and rxtx 2.1. What I don't understand is why your application vendor does not provide everything you need to run their software. FYI: I have librxtxParallel.so and librxtxSerial.so installed at JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is /usr/java/default which is actually a softlink to /usr/java/jre1.6.0_05. -- Jeff From defiantlew at yahoo.com.au Wed Aug 6 16:29:33 2008 From: defiantlew at yahoo.com.au (Lew L) Date: Thu, 7 Aug 2008 08:29:33 +1000 Subject: [Rxtx] Sun's Comm API Documentation References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> Message-ID: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> As a matter of interest is the Sun Comm API documentation available somewhere? I have tried the Sun site but it seems to have been removed. Unless I have missed the documentation for RXTX? I javadocced the RXTX source but information (to me) is minimal. Somewhere I got the impression that the Sun Comm API docs is, or was, compatible with RXTX, what is the best docs to use in conjuntion with RXTX and where may the be available? Cheers Lew From rick_knight at rlknight.com Wed Aug 6 17:18:33 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:18:33 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A3149.4050306@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff I'm not sure if I posted this here or not, but when I try to build RXTX from source I get this install error... make all-am make[1]: Entering directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' make[1]: Nothing to be done for `all-am'. make[1]: Leaving directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 Can you tell me how to get past this error and get RXTX built and installed? Thanks, Rick From bboyes at systronix.com Wed Aug 6 17:40:12 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Wed, 06 Aug 2008 17:40:12 -0600 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: At 16:29 08/06/2008, Lew L wrote: >As a matter of interest is the Sun Comm API documentation available >somewhere? I have tried the Sun site but it seems to have been removed. It's in the file we have posted, link in prev email (sorry, in a huge hurry right now). Javadocs definitely there. >Unless I have missed the documentation for RXTX? I javadocced the RXTX >source but information (to me) is minimal. >Somewhere I got the impression that the Sun Comm API docs is, or was, >compatible with RXTX, what is the best docs to use in conjuntion with RXTX >and where may the be available? Yeah, this is one of my concerns/beefs. There is little documentation for RXTX and it isn't just the same as javaxcomm. I would be willing to help out writing docs for RXTX! Yes really... esp if we can fix the Bluetooth issues. best regards Bruce >Cheers >Lew > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx ------- WWW.SYSTRONIX.COM ---------- Real embedded Java and much more +1-801-534-1017 Salt Lake City, USA From rick_knight at rlknight.com Wed Aug 6 17:54:08 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:54:08 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A39A0.2090309@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff, I would like for my vendor to switch to rxtx 2.1. It would make things much easier for me. I'm not sure why he's still using the javax compatible code. He's a small operation. Re-writing the code to use gnu namespace sounds like a major overhaul. Was it? Thanks, Rick From tjarvi at qbang.org Wed Aug 6 21:35:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:35:12 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: >> >>> Jeff wrote: >>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>>> >>>> >>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things > much easier for me. I'm not sure why he's still using the javax > compatible code. He's a small operation. Re-writing the code to use gnu > namespace sounds like a major overhaul. Was it? > Hi Jeff, The changes are fairly mechanical. Imports need to change and any explicite use of the namespace needs to change such as catching an exception. The following script was made for maintaining rxtx 2.0 but can apply to other needs. It is in the contrib dir with rxtx source. #!/bin/sh # Don't use! :) # # Sat, 03 May 2003 16:45:08 Modifications from J?rg Weule # Create a ed-cmd for the change of one pattern # case $1 in gnu) X=g/javax_comm/s+javax_comm+gnu_io+g ;; javax) X=g/gnu_io/s+gnu_io+javax_comm+g ;; *) echo;echo;echo From the top rxtx directory run;echo;echo -e \\t./ChangePackage.sh gnu;echo -e \\t\\tor;echo -e \\t./ChangePackage.sh javax;echo;echo; exit 0 ;; esac # # ed will be used to keep the owner and mode of the files unchanged. # We have run the ed-script for the characters '.' '/' as well. # "tr _ $D" do the change. # find . -type f -a -print | grep -v $0 | (while read F ; do ( echo $X; echo $X| tr _ /; echo $X| tr _ .; echo w; echo q ) | ed $F 2>&1 >/dev/null done ) # # Now we do little changes at the Makefiles. Hope that all we need. # find . -name Makefile\* -a -print | (while read F ; do cat < References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: On Thu, 7 Aug 2008, Lew L wrote: > As a matter of interest is the Sun Comm API documentation available > somewhere? I have tried the Sun site but it seems to have been removed. > > Unless I have missed the documentation for RXTX? I javadocced the RXTX > source but information (to me) is minimal. > Somewhere I got the impression that the Sun Comm API docs is, or was, > compatible with RXTX, what is the best docs to use in conjuntion with RXTX > and where may the be available? > Hi Lew, The documentation on Sun's website is accurate. The changes that are problematic in 3.0 are on the backside which rxtx used to plug into. http://java.sun.com/products/javacomm/reference/api/index.html CommPortIdentifier may have some minor differences (judging by the authors notes). -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Aug 6 21:46:08 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:46:08 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > If javax.comm.properties is properly installed and you are using a 2.0 version of Sun's commapi with rxtx 2.0, you should not see the library attempt to load libSolarisSerialParallel.so. Sun CommAPI 3.0 will not work with any version of rxtx as it is hard coded to use the shared library. See the INSTALL file with rxtx-2.0 source for more help with the properties file. -- Trent Jarvi tjarvi at qbang.org From jlar310 at gmail.com Thu Aug 7 06:32:06 2008 From: jlar310 at gmail.com (Jeff) Date: Thu, 7 Aug 2008 07:32:06 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > Jeff wrote: >> >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >> wrote: >> >>> >>> Jeff wrote: >>> >>>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>> wrote: >>>> >>>> >>>> >>>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things much > easier for me. I'm not sure why he's still using the javax compatible code. > He's a small operation. Re-writing the code to use gnu namespace sounds like > a major overhaul. Was it? I found it quite easy. In fact, in order to accommodate the transition, I actually separated all of the code that deals directly with the Comm API or RXTX into a helper class. The helper class was then coded to use reflection to determine which library was available and then instantiate the necessary objects. No direct imports of either library are used. The main application just needs to get it's hands on the IO streams and need not deal directly with the libraries. Other programs may not be so simple... But this doesn't really help you unless your vendor forks over the source code... -- Jeff From rick_knight at rlknight.com Thu Aug 7 09:47:12 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Thu, 07 Aug 2008 08:47:12 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: <489B1900.10108@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >>> wrote: >>> >>> >>>> Jeff wrote: >>>> >>>> >>>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>>> copy of the comm.api and I've copied the library >>>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>>> into the proper places. When I try to run the application, I get this >>>>>> error... >>>>>> >>>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>>> /usr/lib/libSolarisSerialParallel.so: >>>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>>> little-endian (Possible cause: endianness mismatch) >>>>>> Caught java.lang.UnsatisfiedLinkError: >>>>>> >>>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>>> >>>>>> while loading driver com.sun.comm.SolarisDriver >>>>>> >>>>>> Is there a way around this error? >>>>>> >>>>>> >>>>>> >>>>> What host OS are you running? From your original post it looks like 32 >>>>> bit Linux. >>>>> >>>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>>> depending on the underlying hardware architecture as well. >>>>> >>>>> >>>>> >>>>> >>>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>>> >>>> >>>> >>> I don't think Sun did binary libraries for Linux in the 2.0 version. >>> Can someone with more historical experience than I confirm that? >>> >>> I recently tried to port a Comm API application from Solaris sparc to >>> Linux x86 and likewise could not get my hands on the binary libraries. >>> I eventually just re-wrote the code to use the gnu namespace packages >>> and rxtx 2.1. >>> >>> What I don't understand is why your application vendor does not >>> provide everything you need to run their software. >>> >>> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >>> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >>> /usr/java/default which is actually a softlink to >>> /usr/java/jre1.6.0_05. >>> >>> >>> >> Jeff, >> >> I would like for my vendor to switch to rxtx 2.1. It would make things much >> easier for me. I'm not sure why he's still using the javax compatible code. >> He's a small operation. Re-writing the code to use gnu namespace sounds like >> a major overhaul. Was it? >> > > I found it quite easy. In fact, in order to accommodate the > transition, I actually separated all of the code that deals directly > with the Comm API or RXTX into a helper class. The helper class was > then coded to use reflection to determine which library was available > and then instantiate the necessary objects. No direct imports of > either library are used. The main application just needs to get it's > hands on the IO streams and need not deal directly with the libraries. > Other programs may not be so simple... > > But this doesn't really help you unless your vendor forks over the > source code... > > Jeff, This may not help me directly, but I'm going to forward this thread to the vendor. I think he'll be open to making things work. Thanks again, Rick Knight From agusmunioz at gmail.com Thu Aug 7 16:39:51 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Thu, 7 Aug 2008 19:39:51 -0300 Subject: [Rxtx] How to send ack? Message-ID: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Hi, I'm still learning about serial communication and I have some doubts. I've got this question about how to do the following thing in rxtx. I have this hardware that connect to a PC using a serial port. These hardware receives data from a telephone line, proccess it, and then send it forward to the serial port. I've used a program named wincomm that shows what information is send it through the serial port and I have the nex behaviour: The hardware has a buffer where all data is stored, that cannot be sent it through the seria port. The program reads the first data send it by the hardware, and keep reading the same data always. There is a button in the application that says enable Ack, and when I click, then the hardware start to send all the stored information, and all the information is shown. I write a class, using rxtx that reads the serial port, and the same thing happens, it remains reading the same (first) data all the time. And I thing something like the enable Ack I'm missing. How can I do this enable Ack from my java code using rxtx? Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080807/e0a0f9a1/attachment-0021.html From ajmas at sympatico.ca Thu Aug 7 18:26:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 7 Aug 2008 20:26:41 -0400 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: <4BF42297-81E2-4BB8-A89F-1D43588379AE@sympatico.ca> On 6-Aug-08, at 19:40 , Bruce Boyes wrote: >> Unless I have missed the documentation for RXTX? I javadocced the >> RXTX >> source but information (to me) is minimal. >> Somewhere I got the impression that the Sun Comm API docs is, or was, >> compatible with RXTX, what is the best docs to use in conjuntion >> with RXTX >> and where may the be available? > > Yeah, this is one of my concerns/beefs. There is little documentation > for RXTX and it isn't just the same as javaxcomm. > > I would be willing to help out writing docs for RXTX! Yes really... > esp if we can fix the Bluetooth issues. If you want to contribute documentation then the best place to do that is the wiki. If there is anything missing or that could be improved on then please do so. If there are any points that you would like to see improved, for which you don't have the knowledge then ask on the mailing list for a volunteer. Andre From florianmanschwetus at gmx.de Fri Aug 8 03:04:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Fri, 08 Aug 2008 11:04:14 +0200 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Message-ID: <489C0C0E.2020401@gmx.de> Agustin Mu?oz schrieb: > Hi, I'm still learning about serial communication and I have some > doubts. I've got this question about how to do the following thing in rxtx. > I have this hardware that connect to a PC using a serial port. These > hardware receives data from a telephone line, proccess it, and then send > it forward to the serial port. I've used a program named wincomm that > shows what information is send it through the serial port and I have the > nex behaviour: > > The hardware has a buffer where all data is stored, that cannot be sent > it through the seria port. > The program reads the first data send it by the hardware, and keep > reading the same data always. > There is a button in the application that says enable Ack, and when I > click, then the hardware start to send all the stored information, and > all the information is shown. > > I write a class, using rxtx that reads the serial port, and the same > thing happens, it remains reading the same (first) data all the time. > And I thing something like the enable Ack I'm missing. > How can I do this enable Ack from my java code using rxtx? Afaik, a look at man ascii reveals: Okt Dez Hex Char 006 6 06 ACK So, i hope this will do the job: send(6); florian > > Thanks in advance > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/5b4965f8/attachment-0021.bin From agusmunioz at gmail.com Fri Aug 8 16:31:00 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 19:31:00 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <489C0C0E.2020401@gmx.de> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> Message-ID: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Hi Florian, thanks for the answer. By send(6) you mean to get the port OutputStream and write a 6? I try that but it didn't work. Any suggestion? Thanks On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < florianmanschwetus at gmx.de> wrote: > Agustin Mu?oz schrieb: > > Hi, I'm still learning about serial communication and I have some doubts. >> I've got this question about how to do the following thing in rxtx. >> I have this hardware that connect to a PC using a serial port. These >> hardware receives data from a telephone line, proccess it, and then send it >> forward to the serial port. I've used a program named wincomm that shows >> what information is send it through the serial port and I have the nex >> behaviour: >> >> The hardware has a buffer where all data is stored, that cannot be sent >> it through the seria port. >> The program reads the first data send it by the hardware, and keep reading >> the same data always. >> There is a button in the application that says enable Ack, and when I >> click, then the hardware start to send all the stored information, and all >> the information is shown. >> >> I write a class, using rxtx that reads the serial port, and the same thing >> happens, it remains reading the same (first) data all the time. And I thing >> something like the enable Ack I'm missing. >> How can I do this enable Ack from my java code using rxtx? >> > Afaik, a look at man ascii reveals: > Okt Dez Hex Char > 006 6 06 ACK > So, i hope this will do the job: > send(6); > > florian > >> >> Thanks in advance >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/7f3fba42/attachment-0020.html From agusmunioz at gmail.com Fri Aug 8 18:39:27 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 21:39:27 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Message-ID: <988288430808081739x7f9e7889id82591d5a9e2b4f6@mail.gmail.com> Ok, Florian, it works!! my problem was that I've been sending, through the OutputStream, the bytes of 6 as a string: out.write("6".getBytes()); but then I realized that you can write an int on an OuptuStream, so I tried that and It works: out.write(6); Thank you for the guidance!! On Fri, Aug 8, 2008 at 7:31 PM, Agustin Mu?oz wrote: > Hi Florian, thanks for the answer. By send(6) you mean to get the port > OutputStream and write a 6? > > I try that but it didn't work. > > Any suggestion? > > Thanks > > > On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < > florianmanschwetus at gmx.de> wrote: > >> Agustin Mu?oz schrieb: >> >> Hi, I'm still learning about serial communication and I have some doubts. >>> I've got this question about how to do the following thing in rxtx. >>> I have this hardware that connect to a PC using a serial port. These >>> hardware receives data from a telephone line, proccess it, and then send it >>> forward to the serial port. I've used a program named wincomm that shows >>> what information is send it through the serial port and I have the nex >>> behaviour: >>> >>> The hardware has a buffer where all data is stored, that cannot be sent >>> it through the seria port. >>> The program reads the first data send it by the hardware, and keep >>> reading the same data always. >>> There is a button in the application that says enable Ack, and when I >>> click, then the hardware start to send all the stored information, and all >>> the information is shown. >>> >>> I write a class, using rxtx that reads the serial port, and the same >>> thing happens, it remains reading the same (first) data all the time. And I >>> thing something like the enable Ack I'm missing. >>> How can I do this enable Ack from my java code using rxtx? >>> >> Afaik, a look at man ascii reveals: >> Okt Dez Hex Char >> 006 6 06 ACK >> So, i hope this will do the job: >> send(6); >> >> florian >> >>> >>> Thanks in advance >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/b918ab3d/attachment-0020.html From florianmanschwetus at gmx.de Sat Aug 9 00:45:43 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Sat, 09 Aug 2008 08:45:43 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4899667C.6010706@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> Message-ID: <489D3D17.9090209@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >> Florian Manschwetus wrote: >>> Ok, sounds fine for the receiving problem. >>> But why i have to wait after each byte when sending a command squence? >>> (the for loop in send command) >> >> Hi Florian, >> I'd imagine you probably don't! You could send all bytes in one go and >> RXTX would send them. The problem is most probably the other end: >> perhaps it has a really small buffer, some non-standard UART, or a >> crazy timing issue. If you attach a terminal to your output and send >> all the bytes of a command in one go they should appear no problem. >> >> Regards, >> Michael Erskine. >> > correct with a terminal on the other end it works, my idea was that this > basic baud has some influence. Could some one explain what it is for? > > Florian To make it more clear, my problem is that i can't use: outputStream.write(byte[]); => Beamer doesn't understand the sequence. (mostly no answer when he answers then *001) when i use this construct instead: for (int i = 0; i < command.length; i++) { this.outputStream.write(command[i]); try { Thread.sleep(25); } catch (InterruptedException e) { // TODO Auto-generated catch block e.printStackTrace(); } } it works nearly reliable. So what could it be? This Basic Baud is what exactly? Florian -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080809/692304ee/attachment-0020.bin From tjarvi at qbang.org Sat Aug 9 16:37:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Aug 2008 16:37:19 -0600 (MDT) Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489D3D17.9090209@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> <489D3D17.9090209@gmx.de> Message-ID: On Sat, 9 Aug 2008, Florian Manschwetus wrote: > Florian Manschwetus schrieb: >> Michael Erskine schrieb: >>> Florian Manschwetus wrote: >>>> Ok, sounds fine for the receiving problem. >>>> But why i have to wait after each byte when sending a command squence? >>>> (the for loop in send command) >>> >>> Hi Florian, >>> I'd imagine you probably don't! You could send all bytes in one go and >>> RXTX would send them. The problem is most probably the other end: perhaps >>> it has a really small buffer, some non-standard UART, or a crazy timing >>> issue. If you attach a terminal to your output and send all the bytes of a >>> command in one go they should appear no problem. >>> >>> Regards, >>> Michael Erskine. >>> >> correct with a terminal on the other end it works, my idea was that this >> basic baud has some influence. Could some one explain what it is for? >> >> Florian > To make it more clear, > my problem is that i can't use: > outputStream.write(byte[]); > => Beamer doesn't understand the sequence. (mostly no answer when he answers > then *001) > > when i use this construct instead: > > for (int i = 0; i < command.length; i++) { > this.outputStream.write(command[i]); > try { > Thread.sleep(25); > } catch (InterruptedException e) { > // TODO Auto-generated catch block > e.printStackTrace(); > } > } > > it works nearly reliable. > > So what could it be? This Basic Baud is what exactly? > I suspect you are using the 'moon protocol' and don't know it. RXTX enables this by default. The buffer on the other end is first in first out while reading. If the buffer is full, the bits are hand carried to the moon and burried. Then if the other side reads a couple bytes, two more bytes go into the buffer followed by more moon protocol. The resulting array of bytes the other side reads may appear to be scrambled until you go to the moon, get the bits and insert them in the right place. Flow control can prevent the default moon protocol and throttles the communiation by almost writing a byte at a time as need be. Hardware flow control is preferable but software flow control should also work. Read and write can appear to hang if the other side is not connected. This is why we don't enable them all the time. If you can't use flow control, you have to take care with the moon protocol and give the other side time to read. That is what your slower version of write is doing. -- Trent Jarvi tjarvi at qbang.org From rxtx at allenjb.me.uk Mon Aug 11 08:06:36 2008 From: rxtx at allenjb.me.uk (AllenJB) Date: Mon, 11 Aug 2008 15:06:36 +0100 Subject: [Rxtx] Disabling EV_RXFLAG Message-ID: <48A0476C.2090800@allenjb.me.uk> Hi all, I'm working with a device which does not use an EvtChar and need to disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an event mask of FD 01 00 00. The reference software I have uses FB 00 00 00. With the rxtx mask I get framing errors which I believe are caused when the EvtChar is received. Is there currently a way with rxtx (I've using rxtx from Java) to disable EV_RXFLAG? If not from Java, where would I start if I wanted to turn the EV_RXFLAG option off in the C code? I've had a grep of the rxtx source code, but I can't see where EV_RXFLAG is being set. Thanks in advance, AllenJB From tjarvi at qbang.org Mon Aug 11 14:17:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Aug 2008 14:17:27 -0600 (MDT) Subject: [Rxtx] Disabling EV_RXFLAG In-Reply-To: <48A0476C.2090800@allenjb.me.uk> References: <48A0476C.2090800@allenjb.me.uk> Message-ID: On Mon, 11 Aug 2008, AllenJB wrote: > Hi all, > > I'm working with a device which does not use an EvtChar and need to > disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an > event mask of FD 01 00 00. The reference software I have uses FB 00 00 > 00. With the rxtx mask I get framing errors which I believe are caused > when the EvtChar is received. > > Is there currently a way with rxtx (I've using rxtx from Java) to > disable EV_RXFLAG? > > If not from Java, where would I start if I wanted to turn the EV_RXFLAG > option off in the C code? I've had a grep of the rxtx source code, but I > can't see where EV_RXFLAG is being set. > > Thanks in advance, > > AllenJB Hi Allen, I'd look at termios.c::tcsetattr() and termios.c::FillDCB() -- Trent Jarvi tjarvi at qbang.org From superdadusa at gmail.com Tue Aug 12 13:57:32 2008 From: superdadusa at gmail.com (John Choi) Date: Tue, 12 Aug 2008 13:57:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. Message-ID: Hi all, Just let you all know I just start to learn Java. I have download the serial comm package and the source code from open source communities.. I was able to verify with the given message string via serial monitor. when the given message string sends to the serial port then the character return added to the end of string by default if I use "Hello World" however if I changed to something else other than "Hello, World" there is no character return add to the end of string. I thing the library download from rxtx.org has implemented for the special strings. I can do like "login\n" in the string message to make character return but I don't want to add this individual custom character for each command return in every static message string I send, Can any who have done this might help me? Basically, something like this,, Write and add function to the program write a command, Reads the respond from a serial device.. Function handles multiple messages, Write: "com open" Read: Welcome to my world" expected Write: "admin" Read: Password?, expected Write: "admin" Read: you are successfully login terminal, expected. And I need to add a separate function handler handles a character return add to the each command above. If anyone can help this I can do the reset? Thank you in advance, John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0016.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SerialIO.java Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0016.pl From Steffen.DETTMER at ingenico.com Wed Aug 13 02:16:38 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 13 Aug 2008 10:16:38 +0200 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: References: Message-ID: <20080813081638.GA25412@elberon.bln.de.ingenico.com> * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > I can do like "login\n" in the string message to make character > return but I don't want to add this individual custom character > for each command return in every static message string I send, and why not?! > Can any who have done this might help me? what's about with writing a small wrapper function adding the carriage return? However, this would be slow, because either you call write two times (very bad) or the string needs to be copied, \n appended and written (since you are using Java Performance probably isn't so critical). Personally I would write `"login\n"' and `username + "\n"' etc., because since it is part of the command it should be part of the command definition string. > Basically, something like this,, Write and add function to the program write > a command, Reads the respond from a serial device.. correctly reading a `line' is more difficult. If you cannot make assumptions about timeouts and/or you need to have low delay, you need to read byte wise. If you need to save CPU resources you might need to add some buffering layer that you can read byte-wise but that is reading blockwise with some small timeout (lets say for serial lines something around byte transmission time times three or so). > /* > * To change this template, choose Tools | Templates > * and open the template in the editor. > */ :) > package joliba; > > /** > * > * @author root > */ :) > // derived from SUN's examples in the javax.comm package > import java.io.*; > import java.util.*; > //import javax.comm.*; // for SUN's serial/parallel port libraries > import gnu.io.*; // for rxtxSerial library > > public class SerialIO implements Runnable, SerialPortEventListener { > static CommPortIdentifier portId; > static CommPortIdentifier saveportId; > static Enumeration portList; > InputStream inputStream; > SerialPort serialPort; > Thread readThread; You need a thread for your synchronous RPC-style protocol? > static String messageString = "Hello, world!"; > static OutputStream outputStream; > static boolean outputBufferEmptyFlag = false; > > public static void main(String[] args) { > boolean portFound = false; > String defaultPort; > > // determine the name of the serial port on several operating systems > String osname = System.getProperty("os.name","").toLowerCase(); > if ( osname.startsWith("windows") ) { > // windows > defaultPort = "COM1"; > } else if (osname.startsWith("linux")) { > // linux > defaultPort = "/dev/ttyS0"; > } else if ( osname.startsWith("mac") ) { > // mac > defaultPort = "????"; > } else { > System.out.println("Sorry, your operating system is not supported"); > return; > } Is such a construction recommended? Isn't there some abstraction (like COM1 working on any platform)? [...] > try { > // activate the OUTPUT_BUFFER_EMPTY notifier > serialPort.notifyOnOutputEmpty(true); > } catch (Exception e) { > System.out.println("Error setting event notification"); > System.out.println(e.toString()); > System.exit(-1); > } I doubt that -1 is defined, probably some 127 or so would be the result, maybe better simply `throw e'? > public void writetoport() { > System.out.println("Writing \""+messageString+"\" to "+serialPort.getName()); > try { > // write string to serial port > outputStream.write(messageString.getBytes()); > } catch (IOException e) {} > } maybe something like /** * Writes the given output string and an additional carriage * return to the current outputStream. */ public void writeStringToPort( /** The output string (without CR). */ String output ) throws IOException { String outputLine = output + "\n"; outputStream.write(outputLine.getBytes()); } ? > > public SerialIO() { > // initalize serial port > try { > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > } catch (PortInUseException e) {} if the port is in use, you continue? Wonder that this works in Java, I would assume serialPort beeing uninitialized which AFAIK is an error in Java. > try { > inputStream = serialPort.getInputStream(); > } catch (IOException e) {} > > try { > serialPort.addEventListener(this); > } catch (TooManyListenersException e) {} > > // activate the DATA_AVAILABLE notifier > serialPort.notifyOnDataAvailable(true); > > try { > // set port parameters > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > } catch (UnsupportedCommOperationException e) {} > > // start the read thread > readThread = new Thread(this); > readThread.start(); > > } I think in all those exception cases you can abort, because it is unlikely that ignoring those errors allow a successful continuation, so in this case maybe it would be better to add a throw clause to the method. > public void run() { > // first thing in the thread, we initialize the write operation > initwritetoport(); > try { > while (true) { > // write string to port, the serialEvent will read it > writetoport(); > Thread.sleep(1000); > } > } catch (InterruptedException e) {} > } Does this make sense? Your `SimpleReadApp' writes one and the same string each second? > public void serialEvent(SerialPortEvent event) { > switch (event.getEventType()) { > case SerialPortEvent.BI: > case SerialPortEvent.OE: > case SerialPortEvent.FE: > case SerialPortEvent.PE: > case SerialPortEvent.CD: > case SerialPortEvent.CTS: > case SerialPortEvent.DSR: > case SerialPortEvent.RI: > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > break; > case SerialPortEvent.DATA_AVAILABLE: > // we get here if data has been received > byte[] readBuffer = new byte[20]; > try { > // read data > while (inputStream.available() > 0) { > int numBytes = inputStream.read(readBuffer); > } > // print data > String result = new String(readBuffer); > System.out.println("Read: "+result); > } catch (IOException e) {} I doubt that this is correct. I would assume you will get a 20 bytes result always, if more bytes would be available they would be printed in a second line but if less bytes are read I'd assume that the buffer/result contains zero bytes from implicite readBuffer contents initialisation (zero is no string terminator in Java AFAIK). > break; > } > } > } oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From florianmanschwetus at gmx.de Wed Aug 13 06:09:31 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 13 Aug 2008 14:09:31 +0200 Subject: [Rxtx] someone has seen such errors? Message-ID: <48A2CEFB.90007@gmx.de> I mean my communication mostly works, but it is far from perfect could this be the reason? Florian Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/949b9947/attachment-0016.bin From superdadusa at gmail.com Wed Aug 13 08:40:32 2008 From: superdadusa at gmail.com (John Choi) Date: Wed, 13 Aug 2008 08:40:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: <20080813081638.GA25412@elberon.bln.de.ingenico.com> References: <20080813081638.GA25412@elberon.bln.de.ingenico.com> Message-ID: Thank you so much Steffen and I will try that suggestion. John On 8/13/08, Steffen DETTMER wrote: > > * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > > I can do like "login\n" in the string message to make character > > return but I don't want to add this individual custom character > > for each command return in every static message string I send, > > and why not?! > > > Can any who have done this might help me? > > what's about with writing a small wrapper function adding the > carriage return? > However, this would be slow, because either you call write two > times (very bad) or the string needs to be copied, \n appended > and written (since you are using Java Performance probably isn't > so critical). > > Personally I would write `"login\n"' and `username + "\n"' etc., > because since it is part of the command it should be part of the > command definition string. > > > Basically, something like this,, Write and add function to the program > write > > a command, Reads the respond from a serial device.. > > correctly reading a `line' is more difficult. If you cannot make > assumptions about timeouts and/or you need to have low delay, you > need to read byte wise. If you need to save CPU resources you > might need to add some buffering layer that you can read > byte-wise but that is reading blockwise with some small timeout > (lets say for serial lines something around byte transmission > time times three or so). > > > /* > > * To change this template, choose Tools | Templates > > * and open the template in the editor. > > */ > > :) > > > package joliba; > > > > /** > > * > > * @author root > > */ > > :) > > > // derived from SUN's examples in the javax.comm package > > import java.io.*; > > import java.util.*; > > //import javax.comm.*; // for SUN's serial/parallel port libraries > > import gnu.io.*; // for rxtxSerial library > > > > public class SerialIO implements Runnable, SerialPortEventListener { > > static CommPortIdentifier portId; > > static CommPortIdentifier saveportId; > > static Enumeration portList; > > InputStream inputStream; > > SerialPort serialPort; > > Thread readThread; > > You need a thread for your synchronous RPC-style protocol? > > > static String messageString = "Hello, world!"; > > static OutputStream outputStream; > > static boolean outputBufferEmptyFlag = false; > > > > public static void main(String[] args) { > > boolean portFound = false; > > String defaultPort; > > > > // determine the name of the serial port on several operating > systems > > String osname = System.getProperty("os.name","").toLowerCase(); > > if ( osname.startsWith("windows") ) { > > // windows > > defaultPort = "COM1"; > > } else if (osname.startsWith("linux")) { > > // linux > > defaultPort = "/dev/ttyS0"; > > } else if ( osname.startsWith("mac") ) { > > // mac > > defaultPort = "????"; > > } else { > > System.out.println("Sorry, your operating system is not > supported"); > > return; > > } > > Is such a construction recommended? Isn't there some abstraction > (like COM1 working on any platform)? > > [...] > > try { > > // activate the OUTPUT_BUFFER_EMPTY notifier > > serialPort.notifyOnOutputEmpty(true); > > } catch (Exception e) { > > System.out.println("Error setting event notification"); > > System.out.println(e.toString()); > > System.exit(-1); > > } > > I doubt that -1 is defined, probably some 127 or so would be the > result, maybe better simply `throw e'? > > > public void writetoport() { > > System.out.println("Writing \""+messageString+"\" to > "+serialPort.getName()); > > try { > > // write string to serial port > > outputStream.write(messageString.getBytes()); > > } catch (IOException e) {} > > } > > maybe something like > > /** > * Writes the given output string and an additional carriage > * return to the current outputStream. > */ > public void > writeStringToPort( > /** The output string (without CR). */ > String output > ) throws IOException > { > String outputLine = output + "\n"; > outputStream.write(outputLine.getBytes()); > } > > ? > > > > > public SerialIO() { > > // initalize serial port > > try { > > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > > } catch (PortInUseException e) {} > > if the port is in use, you continue? Wonder that this works in > Java, I would assume serialPort beeing uninitialized which AFAIK > is an error in Java. > > > try { > > inputStream = serialPort.getInputStream(); > > } catch (IOException e) {} > > > > try { > > serialPort.addEventListener(this); > > } catch (TooManyListenersException e) {} > > > > // activate the DATA_AVAILABLE notifier > > serialPort.notifyOnDataAvailable(true); > > > > try { > > // set port parameters > > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > } catch (UnsupportedCommOperationException e) {} > > > > // start the read thread > > readThread = new Thread(this); > > readThread.start(); > > > > } > > I think in all those exception cases you can abort, because it is > unlikely that ignoring those errors allow a successful > continuation, so in this case maybe it would be better to add a > throw clause to the method. > > > public void run() { > > // first thing in the thread, we initialize the write operation > > initwritetoport(); > > try { > > while (true) { > > // write string to port, the serialEvent will read it > > writetoport(); > > Thread.sleep(1000); > > } > > } catch (InterruptedException e) {} > > } > > Does this make sense? Your `SimpleReadApp' writes one and the > same string each second? > > > public void serialEvent(SerialPortEvent event) { > > switch (event.getEventType()) { > > case SerialPortEvent.BI: > > case SerialPortEvent.OE: > > case SerialPortEvent.FE: > > case SerialPortEvent.PE: > > case SerialPortEvent.CD: > > case SerialPortEvent.CTS: > > case SerialPortEvent.DSR: > > case SerialPortEvent.RI: > > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > > break; > > case SerialPortEvent.DATA_AVAILABLE: > > // we get here if data has been received > > byte[] readBuffer = new byte[20]; > > try { > > // read data > > while (inputStream.available() > 0) { > > int numBytes = inputStream.read(readBuffer); > > } > > // print data > > String result = new String(readBuffer); > > System.out.println("Read: "+result); > > } catch (IOException e) {} > > I doubt that this is correct. I would assume you will get a 20 > bytes result always, if more bytes would be available they would > be printed in a second line but if less bytes are read I'd assume > that the buffer/result contains zero bytes from implicite > readBuffer contents initialisation (zero is no string terminator > in Java AFAIK). > > > break; > > } > > } > > } > > oki, > > Steffen > > About Ingenico Throughout the world businesses rely on Ingenico for secure > and expedient electronic transaction acceptance. Ingenico products leverage > proven technology, established standards and unparalleled ergonomics to > provide optimal reliability, versatility and usability. This comprehensive > range of products is complemented by a global array of services and > partnerships, enabling businesses in a number of vertical sectors to accept > transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged > information. If you are not the addressee or authorized to receive this for > the addressee, you must not use, copy, disclose or take any action based on > this message or any information herein. If you have received this message in > error, please advise the sender immediately by reply e-mail and delete this > message. Thank you for your cooperation. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/73c4135c/attachment-0015.html From ajmas at sympatico.ca Sat Aug 16 07:15:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 09:15:41 -0400 Subject: [Rxtx] someone has seen such errors? In-Reply-To: <48A2CEFB.90007@gmx.de> References: <48A2CEFB.90007@gmx.de> Message-ID: <43B5E8DA-1D93-4D90-809B-AAF35FF724C5@sympatico.ca> On 13-Aug-08, at 08:09 , Florian Manschwetus wrote: > I mean my communication mostly works, but it is far from perfect > could this be the reason? > > Florian > > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control Judging by the error messages this looks related to the driver you are using. Do a search for the following string with you favourite search engine, it should turn up a few hits: ftdi_set_termios FAILED to set databits/stopbits/parity Andre From ajmas at sympatico.ca Sat Aug 16 19:12:04 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 21:12:04 -0400 Subject: [Rxtx] Using SerialPortEvent? Message-ID: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Hi, Could someone tell me how I should be using the SerialPortEvent? Am I meant to be waiting for data and then simply reading from the inputstream? If this is the case why no just block on an inputstream read? Andr? From tjarvi at qbang.org Sat Aug 16 19:41:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 16 Aug 2008 19:41:13 -0600 (MDT) Subject: [Rxtx] Using SerialPortEvent? In-Reply-To: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> References: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Message-ID: On Sat, 16 Aug 2008, Andre-John Mas wrote: > Hi, > > Could someone tell me how I should be using the SerialPortEvent? Am I > meant to be waiting for data and then simply reading from the > inputstream? If this is the case why no just block on an inputstream > read? > Polling for data is fine also. It really depends upon what you are trying to do. For instance, if you require x bytes before reading, you can start polling after data is available. If you read on the same thread as your GUI and are waiting for data in a read, the results may be less than desirable. Java programming is 'usually' event driven rather than polling based. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sat Aug 16 20:10:39 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 22:10:39 -0400 Subject: [Rxtx] Using SerialPortEvent? In-Reply-To: References: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Message-ID: <3E495D4C-BB28-4845-A6AB-984C9A826BDF@sympatico.ca> On 16-Aug-08, at 21:41 , Trent Jarvi wrote: > On Sat, 16 Aug 2008, Andre-John Mas wrote: > >> Hi, >> >> Could someone tell me how I should be using the SerialPortEvent? Am I >> meant to be waiting for data and then simply reading from the >> inputstream? If this is the case why no just block on an inputstream >> read? >> > > Polling for data is fine also. It really depends upon what you are > trying to do. For instance, if you require x bytes before reading, > you can start polling after data is available. If you read on the > same thread as your GUI and are waiting for data in a read, the > results may be less than desirable. > > Java programming is 'usually' event driven rather than polling based. Sounds good. I thought I would use this opportunity to provide a event based version of the TwoWaySerialComm example. Could you just validate it before I add it to the Wiki: package ajmas74.experimental; import gnu.io.CommPort; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; import gnu.io.SerialPortEvent; import gnu.io.SerialPortEventListener; import java.io.IOException; import java.io.InputStream; import java.io.OutputStream; /** * This version of the TwoWaySerialComm example makes use of the * SerialPortEventListener to avoid polling. * * @author ajmas * */ public class TwoWaySerialComm { public TwoWaySerialComm() { super(); } void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { CommPort commPort = portIdentifier.open(this.getClass().getName(),2000); if ( commPort instanceof SerialPort ) { SerialPort serialPort = (SerialPort) commPort; serialPort .setSerialPortParams (57600 ,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); (new Thread(new SerialWriter(out))).start(); serialPort.addEventListener(new SerialReader(in)); } else { System.out.println("Error: Only serial ports are handled by this example."); } } } /** * Handles the input coming from the serial port. A new line character * is treated as the end of a block in this example. */ public static class SerialReader implements SerialPortEventListener { private InputStream in; private byte[] buffer = new byte[1024]; public SerialReader ( InputStream in ) { this.in = in; } public void serialEvent(SerialPortEvent arg0) { int data; try { int len = 0; while ( ( data = in.read()) > -1 ) { if ( data != '\n' ) { break; } buffer[len++] = (byte) data; } System.out.print(new String(buffer,0,len)); } catch ( IOException e ) { e.printStackTrace(); System.exit(-1); } } } /** */ public static class SerialWriter implements Runnable { OutputStream out; public SerialWriter ( OutputStream out ) { this.out = out; } public void run () { try { int c = 0; while ( ( c = System.in.read()) > -1 ) { this.out.write(c); } } catch ( IOException e ) { e.printStackTrace(); System.exit(-1); } } } public static void main ( String[] args ) { try { (new TwoWaySerialComm()).connect("COM3"); } catch ( Exception e ) { e.printStackTrace(); } } } From lfarkas at lfarkas.org Tue Aug 19 07:32:59 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Tue, 19 Aug 2008 15:32:59 +0200 Subject: [Rxtx] JNI or CNI Message-ID: <48AACB8B.9060606@lfarkas.org> hi, what is the current recommended way to rxtx on linux JNI or it's better to use CNI? is the CNI version fully functional and the same level as the JNI? i currently try to make a rhel/centos/fedora rpm for rxtx but has many problems with the standard dir structure. yours. -- Levente "Si vis pacem para bellum!" From lfarkas at lfarkas.org Tue Aug 19 08:47:34 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Tue, 19 Aug 2008 16:47:34 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel Message-ID: <48AADD06.7040809@lfarkas.org> hi, newer or not so newer linux kernel do not contain the UTS_RELEASE so the current rxtx is not compile on the latest kernels. even if it's commented out in the cvs configure there are other places. i attcahed a patch which fix it (or at least doesn't cause error at non-debug build). ps. is there any plan to the new 2.1-8 release in the near future? there are many changes (at least the license change in all file and in this case create a diff is very difficult)? the latest release more then 2 years old:-( -- Levente "Si vis pacem para bellum!" -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-2.1-uts.patch Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080819/ab5d38ac/attachment-0009.pl From ajmas at sympatico.ca Tue Aug 19 16:21:53 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 19 Aug 2008 18:21:53 -0400 Subject: [Rxtx] Event based example Message-ID: <24735BFB-B088-4B84-8173-FE98DF63B12F@sympatico.ca> Hi, I have just posted an example of using SerialPortEventListener in the Wiki: http://rxtx.qbang.org/wiki/index.php/Event_Based_Two_Way_Communication If you see any issues please could you let me know, or makes the changes. Andre From Martin.Oberhuber at windriver.com Fri Aug 22 04:02:24 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 22 Aug 2008 12:02:24 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <48AADD06.7040809@lfarkas.org> References: <48AADD06.7040809@lfarkas.org> Message-ID: <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> Farkas, there are indeed efforts to get a new RXTX release out the door. Your experience as a package maintainer would likely be helpful during these efforts, since I'd think it makes sense to keep the patches minimal that you must make to have the source compile in your environment. What are the things that you find problematic, apart from the UTS thing that you have mentioned before? What is the timing that you have in mind for your package? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Farkas Levente > Sent: Tuesday, August 19, 2008 4:48 PM > To: rxtx at qbang.org > Subject: [Rxtx] UTS_RELEASE not defined in newer kernel > > hi, > newer or not so newer linux kernel do not contain the > UTS_RELEASE so the > current rxtx is not compile on the latest kernels. even if it's > commented out in the cvs configure there are other places. > i attcahed a patch which fix it (or at least doesn't cause error at > non-debug build). > > ps. is there any plan to the new 2.1-8 release in the near > future? there > are many changes (at least the license change in all file and in this > case create a diff is very difficult)? the latest release more then 2 > years old:-( > > -- > Levente "Si vis pacem para bellum!" > From lfarkas at lfarkas.org Fri Aug 22 04:36:26 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Fri, 22 Aug 2008 12:36:26 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> References: <48AADD06.7040809@lfarkas.org> <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> Message-ID: <48AE96AA.6090505@lfarkas.org> hi, the packages already build for fedora-9 and centos-5 and here: http://www.lfarkas.org/linux/packages/ what i've to patch, the UTS, the configure script, but it's already fixed in the cvs (in another way) and the loadlibrary. the reasons for last one can be found here: https://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_files_that_use_JNI after we test it i'd like to add these packages to fedora and epel main repository (that's why it's be useful a new release after 2 years:-) imho versions are cheap and why not just release 2.1-8? the real code changes are minimal and if something critical bug found still can release 2.1-9:-) ps. and would be better to use simple number for version like 2.1-7 rather then 2.1-7v2. Oberhuber, Martin wrote: > Farkas, > > there are indeed efforts to get a new RXTX release out the > door. Your experience as a package maintainer would likely > be helpful during these efforts, since I'd think it makes > sense to keep the patches minimal that you must make to > have the source compile in your environment. > > What are the things that you find problematic, apart from > the UTS thing that you have mentioned before? > > What is the timing that you have in mind for your package? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >> On Behalf Of Farkas Levente >> Sent: Tuesday, August 19, 2008 4:48 PM >> To: rxtx at qbang.org >> Subject: [Rxtx] UTS_RELEASE not defined in newer kernel >> >> hi, >> newer or not so newer linux kernel do not contain the >> UTS_RELEASE so the >> current rxtx is not compile on the latest kernels. even if it's >> commented out in the cvs configure there are other places. >> i attcahed a patch which fix it (or at least doesn't cause error at >> non-debug build). >> >> ps. is there any plan to the new 2.1-8 release in the near >> future? there >> are many changes (at least the license change in all file and in this >> case create a diff is very difficult)? the latest release more then 2 >> years old:-( >> >> -- >> Levente "Si vis pacem para bellum!" >> -- Levente "Si vis pacem para bellum!" From tjarvi at qbang.org Fri Aug 22 18:50:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Aug 2008 18:50:32 -0600 (MDT) Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <48AE96AA.6090505@lfarkas.org> References: <48AADD06.7040809@lfarkas.org> <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> <48AE96AA.6090505@lfarkas.org> Message-ID: Hi Farkas, The v2 was simply the second build - no code changes. We are comming out with a new release shortly. I would encourage working with distros as you are. The building of rxtx turns out to be a bottle neck in quick releases. We do want stable releases that work for a year or more but I would have no problems with quicker cycles on developing work. I would have no problem working with someone that did builds that receive less testing more often but they do have to come out for multiple platforms from this end. Thanks for the links. On Fri, 22 Aug 2008, Farkas Levente wrote: > hi, > the packages already build for fedora-9 and centos-5 and here: > http://www.lfarkas.org/linux/packages/ > what i've to patch, the UTS, the configure script, but it's already > fixed in the cvs (in another way) and the loadlibrary. the reasons for > last one can be found here: > https://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_files_that_use_JNI > after we test it i'd like to add these packages to fedora and epel main > repository (that's why it's be useful a new release after 2 years:-) > imho versions are cheap and why not just release 2.1-8? the real code > changes are minimal and if something critical bug found still can > release 2.1-9:-) > > ps. and would be better to use simple number for version like 2.1-7 > rather then 2.1-7v2. > > Oberhuber, Martin wrote: >> Farkas, >> >> there are indeed efforts to get a new RXTX release out the >> door. Your experience as a package maintainer would likely >> be helpful during these efforts, since I'd think it makes >> sense to keep the patches minimal that you must make to >> have the source compile in your environment. >> >> What are the things that you find problematic, apart from >> the UTS thing that you have mentioned before? >> >> What is the timing that you have in mind for your package? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >>> On Behalf Of Farkas Levente >>> Sent: Tuesday, August 19, 2008 4:48 PM >>> To: rxtx at qbang.org >>> Subject: [Rxtx] UTS_RELEASE not defined in newer kernel >>> >>> hi, >>> newer or not so newer linux kernel do not contain the >>> UTS_RELEASE so the >>> current rxtx is not compile on the latest kernels. even if it's >>> commented out in the cvs configure there are other places. >>> i attcahed a patch which fix it (or at least doesn't cause error at >>> non-debug build). >>> >>> ps. is there any plan to the new 2.1-8 release in the near >>> future? there >>> are many changes (at least the license change in all file and in this >>> case create a diff is very difficult)? the latest release more then 2 >>> years old:-( >>> >>> -- >>> Levente "Si vis pacem para bellum!" >>> > > > From andy at triera.net Sat Aug 23 15:17:44 2008 From: andy at triera.net (Andy Rozman) Date: Sat, 23 Aug 2008 21:17:44 +0000 Subject: [Rxtx] port not identified on FreeBSD In-Reply-To: References: Message-ID: <48B07E78.2030306@triera.net> Hi ! I have one small problem... I have started using FreeBSD in last few days and I have come accross a problem with rxtx on FreeBSD. I am using usb-to-serial converter, which is identified under FreeBSD without problem as ucom0, and creates link under /dev called ttyU0, which is correct way to be done under FreeBSD (if device would be unidentified it would be called ugen0 - as usb generic). Problem is that I say to rxtx to get my all serial ports this one is not among them. Which names are permissable under linux-like implementations? Which will be accepted as serial ports? Andy From tjarvi at qbang.org Sat Aug 23 13:57:45 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 23 Aug 2008 13:57:45 -0600 (MDT) Subject: [Rxtx] port not identified on FreeBSD In-Reply-To: <48B07E78.2030306@triera.net> References: <48B07E78.2030306@triera.net> Message-ID: On Sat, 23 Aug 2008, Andy Rozman wrote: > Hi ! > > I have one small problem... I have started using FreeBSD in last few > days and I have come accross a problem with rxtx on FreeBSD. > > I am using usb-to-serial converter, which is identified under FreeBSD > without problem as ucom0, and creates link under /dev called > ttyU0, which is correct way to be done under FreeBSD (if device would be > unidentified it would be called ugen0 - as usb generic). Problem is that > I say to rxtx to get my all serial ports this one is not among them. > Which names are permissable under linux-like implementations? Which will > be accepted as serial ports? > > Andy > Thanks Andy! We will add ttyU* to FreeBSD. For now you can use properties to enable the port. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting#How_does_rxtx_detect_ports.3F__Can_I_override_it.3F The fix: diff -u -r1.16.2.59 RXTXCommDriver.java --- RXTXCommDriver.java 18 Nov 2007 22:32:41 -0000 1.16.2.59 +++ RXTXCommDriver.java 23 Aug 2008 19:55:25 -0000 @@ -644,6 +644,7 @@ { String[] Temp = { "ttyd", //general purpose serial ports + "ttyU", //general purpose USB serial ports "cuaa", //dialout serial ports "ttyA", //Specialix SI/XIO dialin ports "cuaA", //Specialix SI/XIO dialout ports -- Trent Jarvi tjarvi at qbang.org From rick_knight at rlknight.com Mon Aug 4 13:25:10 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Mon, 04 Aug 2008 12:25:10 -0700 Subject: [Rxtx] Sun's Comm API? Message-ID: <48975796.4010600@rlknight.com> I have an application that requires the javax compatible version of RXTX and Sun's comm api. I've been able to download and extract the version of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api anywhere. Can someone tell me where I can find it? Or maybe send me a copy? Also, when I try to build RXTX, configure and make complete successfully but make install failes with this error libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 I've never come accross this error before. How can I get past it? Thanks, Rick From bboyes at systronix.com Mon Aug 4 19:10:01 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:10:01 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48975796.4010600@rlknight.com> References: <48975796.4010600@rlknight.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/cb9c6167/attachment-0025.html From bboyes at systronix.com Mon Aug 4 19:12:37 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:12:37 -0600 Subject: [Rxtx] Towards an RXTX release - CSR BT/USB chipset In-Reply-To: <488FB7E7.8000802@gmail.com> References: <460801A4097E3D4CA04CC64EE648584806C56CF0@ism-mail03.corp.ad.wrs.com> <13557-75390@sneakemail.com> <20980-23424@sneakemail.com> <488FB7E7.8000802@gmail.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/52236088/attachment-0025.html From tjarvi at qbang.org Mon Aug 4 19:42:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 19:42:21 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: On Mon, 4 Aug 2008, Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: > I have an application that requires the javax compatible > version of RXTX > and Sun's comm api. I've been able to download and extract > the version > of RXTX that I need (2.0-7pre2) but I can't find Sun's camm > api > anywhere. Can someone tell me where I can find it? Or maybe > send me a > > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm port > support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have just > a ZIP with only the .class JAR file - no source or docs), has a readme > with these comments: > > This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release.? The 2.0.3 release itself is > no longer distributed.? comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project.? The RxTx project (http://www.rxtx.org ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org) was opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support.? Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins.? Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > ? > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > I hope that is helpful! > It would be nice to work with Sun to resolve those longstanding issues. But it may not be practical unless the process goes as fast and painless as the grandfathering of commapi did. Another option may be the old kaffe extensions that moved to gnu classpathx. These don't have the native libraries but should provide the 2.0 interface and the javax.comm.properties mechansim for SPI. http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Mon Aug 4 20:23:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Mon, 04 Aug 2008 20:23:57 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4897B9BD.5070809@ergotech.com> Has there been any work/would it be possible, to layer a javacomm look-alike on top of the GNU code? The goal is not to move the javax code forward, but to emulate the "legacy" javax packages for people who still need this. Jim Trent Jarvi wrote: > On Mon, 4 Aug 2008, Bruce Boyes wrote: > >> At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible >> version of RXTX >> and Sun's comm api. I've been able to download and extract >> the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm >> api >> anywhere. Can someone tell me where I can find it? Or maybe >> send me a >> >> >> javaxcomm has had a sort of on-again off-again history. The windoze >> version has been languishing for years (literally) but there are newer >> versions for other OS's. >> >> We try to keep links on one of our help pages current: >> http://www.practicalembeddedjava.com/tools/javatools_list.html >> which gets you to here: >> http://java.sun.com/products/javacomm/ >> where it says in fact they no longer even support Windows and Mac: >> "Implementations of the API are currently available for Solaris SPARC, >> Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so >> someone could support it. But I guess that's part of the reason RXTX >> exists! >> >> So one of Sun's own products, SunSPOT, has to use RXTX to get comm port >> support. >> >> The version we use is 2.0 from 11/15/1998. I have posted it on our >> website, which is within the terms of the license agreement contained >> therein (as I understand it). >> >> The last version of javaxcomm for Windows, 2.0.3, (for which I have just >> a ZIP with only the .class JAR file - no source or docs), has a readme >> with these comments: >> >> This distribution contains the comm.jar file original part >> of the COMMAPI 2.0.3 release. The 2.0.3 release itself is >> no longer distributed. comm.jar, which contains the comm >> API java class files (eg. Sun's binary implementation of the >> interface classes), is being made available, unsupported, >> with no obligation to fix bugs, at the request of the RXTX >> project. The RxTx project (http://www.rxtx.org ), uses the >> comm.jar class files, but provides their own native library >> components to provide support for other platforms. >> >> The 2.0.3 comm.jar is being provided in this way because >> as of COMMAPI 3.x, the java binary implementation forked and >> became incompatible with the RxTx project's native code. >> Due to the lack of a clear business case, and to resource >> constraints, no additional resources are being >> provided to provide an alternative engineering solution >> at the time of writing. >> >> RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: >> >> Ultimately the COMMAPI would be better served if a Java >> Community Process JSR (http://www.jcp.org) was opened and >> the COMMAPI was rearchitected to provide a more pluggable >> framework to improve cross-platform support. Such an >> architecture would embody a better defined and better >> documented SPI interface, including a way for comm. ports >> to be revealed to the client application through the API >> via platform-aware plugins. Similarly, native code used >> to access comm port in general could be handled more >> flexibly using a plugin model, whereby on any platform, >> multiple native modules could be in use simultaneously. >> >> Since there are now various ways serial ports can be implemented >> and accessed, modular comm. port JNI native libraries would be >> of benefit insofar as removing the burden of over-generalization >> from any single native component, or inversely, by relieving the >> implicit constraint that comm. drivers be accessed only via a >> monolithic mechanism, such as the UNIX vnode interface. >> >> paul.klissner at sun.com >> 6/10/06 >> >> I hope that is helpful! >> > > It would be nice to work with Sun to resolve those longstanding issues. > But it may not be practical unless the process goes as fast and painless > as the grandfathering of commapi did. > > Another option may be the old kaffe extensions that moved to gnu > classpathx. These don't have the native libraries but should provide > the 2.0 interface and the javax.comm.properties mechansim for SPI. > > http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Mon Aug 4 21:09:15 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 21:09:15 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? Message-ID: Hi Jim, I will not step into the javax.comm namespace without Sun's explicite permission. I fully understand the pain point you are trying to address. In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm Linux) - which remains an integral part of rxtx. At the time it was a win for Sun and rxtx. The Sun commapi license is/was fairly clear that rxtx should not step into that namespace. It made sense as Sun was active in that space and rxtx may go into another namespace - it was an experiment in working with Sun. This may sound silly looking at something that happened almost 10 years ago. In a community of respect which Sun helped create, there is no question about what to do. I hope eventually Sun will step up and do a right thing too. I agree that this is hurting the API more than helping it. There are also questions about how to replace the API in the long term which includes HID support which isn't going well so far. Others that can't even look at Sun's javax.comm today and can look at Kaffe's contribution to classpathx can easily work around such restrictions. On Mon, 4 Aug 2008, Jim Redman wrote: > Has there been any work/would it be possible, to layer a javacomm > look-alike on top of the GNU code? > > The goal is not to move the javax code forward, but to emulate the > "legacy" javax packages for people who still need this. > > Jim > > Trent Jarvi wrote: >> >> It would be nice to work with Sun to resolve those longstanding issues. >> But it may not be practical unless the process goes as fast and painless >> as the grandfathering of commapi did. >> >> Another option may be the old kaffe extensions that moved to gnu >> classpathx. These don't have the native libraries but should provide >> the 2.0 interface and the javax.comm.properties mechansim for SPI. >> >> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From florianmanschwetus at gmx.de Tue Aug 5 05:04:46 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 13:04:46 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: References: <48971C1F.9020806@gmx.de> Message-ID: <489833CE.1040801@gmx.de> Just look at sendCommand in this method I have to place a Thread.sleep(20) after each byte send to get working. Even the event based receive doesn't work fine but this could be may stupidness. The specifikation document (it is on the last pages of the manual) for the beamer could be found on: http://www.optoma.co.uk/support.aspx Florian Manschwetus Trent Jarvi schrieb: > > Hi Florian > > Sorry for the top post in advance. I worry you may not see my answer > under all your code :) > > I have not received this email before. This is 500k of code which I > don't have time to read. I can spend about 5 min on each hobby email > and still get to work in the morning. I have a couple suggestions for > how to get an answer. > > First, cut out your comments and extra code so you can demonstrate the > question (I might even glance and see what is wrong then). Don't go for > a working final product. Isolate the problem using a simple program and > then ask with that as an example. If I did what you just did, I'd have > to post 3/4 of a million lines of code :) > > Second, join the rxtx mail-list and ask there. This will give you 100x > more eyes. I'll also read and try to follow. > > -- > taj > > > > On Mon, 4 Aug 2008, Florian Manschwetus wrote: > >> It could be that my university account is blocked by filters so >> resending from here. >> >> >> Topic is to control Optoma HD80 beamer using rs232 serial chat. >> This code is able to detect power state and switch the beamer on / off. >> connected is the beamer using a digitus usb 2.0 serial adapter with an >> FT232 USB-Serial adapter the systems architecture is amd64. >> >> Please take a look in the sendCommand routine i have to place theire >> those Thread.sleep to get it working. >> Now the question is this correct or is there a better way to get this >> working correctly? >> >> In the javadoc coming with the install i found this: >> setBaudBase >> >> public boolean setBaudBase(int BaudBase) >> throws UnsupportedCommOperationException, >> java.io.IOException >> >> Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 >> before using. >> >> could this explain the error? >> I attached my java source and the protocol description for the beamer >> (available on vendor website). >> >> thx, >> Florian Manschwetus >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: TestRS232.java Type: text/x-java Size: 9143 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0050.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0051.bin From michael.erskine at ketech.com Tue Aug 5 05:53:49 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Tue, 5 Aug 2008 12:53:49 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489833CE.1040801@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> > Just look at sendCommand in this method I have to place a > Thread.sleep(20) after each byte send to get working. Even the event > based receive doesn't work fine but this could be may stupidness. Hi Florian, Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. Regards, Michael Erskine. From florianmanschwetus at gmx.de Tue Aug 5 07:28:15 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:28:15 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> Message-ID: <4898556F.8000208@gmx.de> Michael Erskine schrieb: >> Just look at sendCommand in this method I have to place a >> Thread.sleep(20) after each byte send to get working. Even the event >> based receive doesn't work fine but this could be may stupidness. > > Hi Florian, > > Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. > > Regards, > Michael Erskine. > Ok, sounds fine for the receiving problem. But why i have to wait after each byte when sending a command squence? (the for loop in send command) Florian > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/284f350c/attachment-0024.bin From florianmanschwetus at gmx.de Tue Aug 5 07:44:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:44:14 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <4898592E.2020908@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >>> Just look at sendCommand in this method I have to place a >>> Thread.sleep(20) after each byte send to get working. Even the event >>> based receive doesn't work fine but this could be may stupidness. >> >> Hi Florian, >> >> Yes, naturally you'll have to wait for a response from the other end. >> Why not wait for notification from the event thread perhaps using a >> BlockingDeque rather than your LinkedList. Generally I >> try to decouple all input and output streams: in your case your >> application is operating synchronously like the "expect" program >> (http://expect.nist.gov/) so waits (or timeouts) will need to be >> factored in. >> >> Regards, >> Michael Erskine. >> > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) > > Florian Furthermore there is this basic baud with this confusing javadoc entry: public boolean setBaudBase(int BaudBase) throws UnsupportedCommOperationException, java.io.IOException Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 before using. maybe this could explain something Florian >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/006c7425/attachment-0024.bin From jredman at ergotech.com Tue Aug 5 09:13:36 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 05 Aug 2008 09:13:36 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: Message-ID: <48986E20.3060104@ergotech.com> Trent, So two issues: 1) Technically I'm still not sure how easy/practical a layer would be. The problems are always classes like listeners, and wrapping returns of gnu.io classes. I really see it as a "delegate" type of concept. Any thoughts or ideas of the practicality of this approach? The idea is not to modify RXTX. 2) Javax. The javax namespace does seem to be in widespread use outside of Sun (the same is true for the java namespace). The classpath extensions, or some other location, should be interested in a JavaComm implementation even if it does have dependencies on RXTX. Would you have any philosophical objection to an approach like that? Of course, I suspect it might be better if someone with that authority at Sun would admit that the javax namespace is already in the wild and that there is no problem with it being used within RXTX. Jim Trent Jarvi wrote: > Hi Jim, > > I will not step into the javax.comm namespace without Sun's explicite > permission. I fully understand the pain point you are trying to address. > > In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm > Linux) - which remains an integral part of rxtx. At the time it was a win for > Sun and rxtx. > > The Sun commapi license is/was fairly clear that rxtx should not step into that > namespace. It made sense as Sun was active in that space and rxtx may go into > another namespace - it was an experiment in working with Sun. > > This may sound silly looking at something that happened almost 10 years ago. > In a community of respect which Sun helped create, there is no question about > what to do. I hope eventually Sun will step up and do a right thing too. > > I agree that this is hurting the API more than helping it. There are also > questions about how to replace the API in the long term which includes HID > support which isn't going well so far. > > Others that can't even look at Sun's javax.comm today and can look at Kaffe's > contribution to classpathx can easily work around such restrictions. > > On Mon, 4 Aug 2008, Jim Redman wrote: > >> Has there been any work/would it be possible, to layer a javacomm >> look-alike on top of the GNU code? >> >> The goal is not to move the javax code forward, but to emulate the >> "legacy" javax packages for people who still need this. >> >> Jim >> >> Trent Jarvi wrote: >>> It would be nice to work with Sun to resolve those longstanding issues. >>> But it may not be practical unless the process goes as fast and painless >>> as the grandfathering of commapi did. >>> >>> Another option may be the old kaffe extensions that moved to gnu >>> classpathx. These don't have the native libraries but should provide >>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>> >>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From sandeep at genevasoftech.com Tue Aug 5 11:18:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Tue, 05 Aug 2008 22:48:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <48988B6C.5080409@genevasoftech.com> Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. *-- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/ad20f1cb/attachment-0024.html From Martin.Oberhuber at windriver.com Tue Aug 5 13:30:17 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Tue, 5 Aug 2008 21:30:17 +0200 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Sandeep, shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on Sol7 but I've successfully run it on Sol9 and Sol10. Or is your request really about a native 64bit variant? I'm afraid that then you're out of luck since I think that quite a bit of RXTX is not yet ready for 64 bit. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Sandeep Kumar K Sent: Tuesday, August 05, 2008 7:19 PM To: rxtx at qbang.org Subject: [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so for Solaris 9 Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. -- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/81b7f988/attachment-0024.html From tjarvi at qbang.org Tue Aug 5 22:38:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 22:38:34 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 5 Aug 2008, Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built > on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid that > then > you're out of luck since I think that quite a bit of RXTX is not yet > ready > for 64 bit. > While rxtx-2.1-7 probably has problems, The CVS code should be OK for 64 bit Solaris. If it isn't, let me know and I'll find which patch is missing. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Aug 5 23:13:00 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 23:13:00 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48986E20.3060104@ergotech.com> References: <48986E20.3060104@ergotech.com> Message-ID: On Tue, 5 Aug 2008, Jim Redman wrote: > Trent, > > So two issues: > > 1) Technically I'm still not sure how easy/practical a layer would be. The > problems are always classes like listeners, and wrapping returns of gnu.io > classes. I really see it as a "delegate" type of concept. Any thoughts or > ideas of the practicality of this approach? The idea is not to modify RXTX. I have not put too much thought into this. I assume you want what rxtx 2.0 provided to tie into javax.comm implementations. More classes could be added to rxtx 2.1-7 for SPI support. Maintaining rxtx-2.0 could also be handed to someone if they like. > > 2) Javax. The javax namespace does seem to be in widespread use outside of > Sun (the same is true for the java namespace). The classpath extensions, or > some other location, should be interested in a JavaComm implementation even > if it does have dependencies on RXTX. Would you have any philosophical > objection to an approach like that? > No problems. Classpathx would be a possible place to do it. I'd suggest thinking twice about what this involves in practical terms. You would be wanting to revive the 2.0 API while Sun is at 3.0 and grandfathering the JSR. This undermines the main reason (established api) for using the javax.comm namespace and does not leave such a project in a good position. The only win I see here is maintaining support for applications that can't migrate namespaces. Not that that isn't important. At some point it is going to be less work to just edit the bytecode :) Such a javax.comm effort would also be signing up new projects that decided to use the work up for concerns they probably will not understand or expect. That probably isn't a good path to facilitate for new projects at this time. We will put a good faith effort to work well with others but keep in mind the project has limited bandwidth for such efforts. > Of course, I suspect it might be better if someone with that authority at Sun > would admit that the javax namespace is already in the wild and that there is > no problem with it being used within RXTX. > > Jim > > Trent Jarvi wrote: >> Hi Jim, >> >> I will not step into the javax.comm namespace without Sun's explicite >> permission. I fully understand the pain point you are trying to address. >> >> In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java >> Comm Linux) - which remains an integral part of rxtx. At the time it was a >> win for Sun and rxtx. >> >> The Sun commapi license is/was fairly clear that rxtx should not step into >> that namespace. It made sense as Sun was active in that space and rxtx may >> go into another namespace - it was an experiment in working with Sun. >> >> This may sound silly looking at something that happened almost 10 years >> ago. In a community of respect which Sun helped create, there is no >> question about what to do. I hope eventually Sun will step up and do a >> right thing too. >> >> I agree that this is hurting the API more than helping it. There are also >> questions about how to replace the API in the long term which includes HID >> support which isn't going well so far. >> >> Others that can't even look at Sun's javax.comm today and can look at >> Kaffe's contribution to classpathx can easily work around such >> restrictions. >> >> On Mon, 4 Aug 2008, Jim Redman wrote: >> >>> Has there been any work/would it be possible, to layer a javacomm >>> look-alike on top of the GNU code? >>> >>> The goal is not to move the javax code forward, but to emulate the >>> "legacy" javax packages for people who still need this. >>> >>> Jim >>> >>> Trent Jarvi wrote: >>>> It would be nice to work with Sun to resolve those longstanding issues. >>>> But it may not be practical unless the process goes as fast and painless >>>> as the grandfathering of commapi did. >>>> >>>> Another option may be the old kaffe extensions that moved to gnu >>>> classpathx. These don't have the native libraries but should provide >>>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>>> >>>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From sandeep at genevasoftech.com Wed Aug 6 00:03:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Wed, 06 Aug 2008 11:33:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: <48993EB8.30107@genevasoftech.com> Thank you Mr. Martin for your suggestion. The native file which is given in rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am getting the following error . Any suggestions to solve this issue. I am using Solaris SPARC 64 bit machine. ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) thrown while loading gnu.io.RXTXCommDriver Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(Unknown Source) at java.lang.ClassLoader.loadLibrary(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) at com.ReadFromModem.main(ReadFromModem.java:84) * * *Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid > that then > you're out of luck since I think that quite a bit of RXTX is not yet ready > for 64 bit. > > Cheers, > -- > *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > ------------------------------------------------------------------------ > *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On > Behalf Of *Sandeep Kumar K > *Sent:* Tuesday, August 05, 2008 7:19 PM > *To:* rxtx at qbang.org > *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so > for Solaris 9 > > Hi, > > Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 > bit machine. The librxtxSerial.so given in website is for Solaris 8. > > *-- > > Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/1e920343/attachment-0024.html From tjarvi at qbang.org Wed Aug 6 00:21:42 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 00:21:42 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <48993EB8.30107@genevasoftech.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> <48993EB8.30107@genevasoftech.com> Message-ID: Hi Sandeep You may be out of luck unless you can compile the 2.1 src in CVS (requires gnu make and gcc). But you could try the ToyBox(R)(TM) which is a collection of WiLdLy untested cross compiled 2.1-7 binaries covering everything from the ibm z series to embeded arm/ppc. To give an idea how poorly these are tested, I don't even know if z series machines have a serial port. ftp://www.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Solaris They should at least match the binary types. Actually, I think if you use the rxtx jar from CVS with that file, it should 'work' as the fix for 64 bits was in java not the native code. You could just cd rxtx*/src; javac *.java then jar -cf RXTXcomm.jar `find -name \*.class` to create the hybrid which will complain about version information a bit. On Wed, 6 Aug 2008, Sandeep Kumar K wrote: > Thank you Mr. Martin for your suggestion. The native file which is given in > rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am > getting the following error . > Any suggestions to solve this issue. > I am using Solaris SPARC 64 bit machine. > > ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar > java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 > (Possible cause: architecture word > width mismatch) thrown while loading gnu.io.RXTXCommDriver > Exception in thread "main" java.lang.UnsatisfiedLinkError: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF > class: ELFCLASS64 (Possible cause: > architecture word width mismatch) > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(Unknown Source) > at java.lang.ClassLoader.loadLibrary(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > at com.ReadFromModem.main(ReadFromModem.java:84) > > * > * > > *Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > > > Oberhuber, Martin wrote: >> Sandeep, >> shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse >> variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on >> Sol7 but I've successfully run it on Sol9 and Sol10. >> Or is your request really about a native 64bit variant? I'm afraid that >> then >> you're out of luck since I think that quite a bit of RXTX is not yet ready >> for 64 bit. >> Cheers, >> -- >> *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> ------------------------------------------------------------------------ >> *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On >> Behalf Of *Sandeep Kumar K >> *Sent:* Tuesday, August 05, 2008 7:19 PM >> *To:* rxtx at qbang.org >> *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so >> for Solaris 9 >> >> Hi, >> >> Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 >> bit machine. The librxtxSerial.so given in website is for Solaris 8. >> >> *-- >> Thanks & Regards >> >> Sandeep Kumar K >> Sr. Software Engineer >> Geneva Software Technologies >> Whitefield, Bangalore >> Mob : 9880193454* >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> From michael.erskine at ketech.com Wed Aug 6 01:39:28 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 6 Aug 2008 08:39:28 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Florian Manschwetus wrote: > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) Hi Florian, I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. Regards, Michael Erskine. From florianmanschwetus at gmx.de Wed Aug 6 02:53:16 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 06 Aug 2008 10:53:16 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Message-ID: <4899667C.6010706@gmx.de> Michael Erskine schrieb: > Florian Manschwetus wrote: >> Ok, sounds fine for the receiving problem. >> But why i have to wait after each byte when sending a command squence? >> (the for loop in send command) > > Hi Florian, > I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. > > Regards, > Michael Erskine. > correct with a terminal on the other end it works, my idea was that this basic baud has some influence. Could some one explain what it is for? Florian > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/c2b4fa84/attachment-0024.bin From rick_knight at rlknight.com Wed Aug 6 13:01:07 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:01:07 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F4F3.3020707@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > I have an application (Readerware) that uses RXTX with Javax to access the serial port. This used to work fine under previous Linux' and Java, but something has changed, I assume with Java itself , that is causing the application to fail with a link error. The application is not able to find librxtxSerialParallel.so. RXTX supplies librxtxSerial.so and librxtxParallel.so, but not librxtxSerialParallel.so. Where can I get librxtxSerialParallel.so, or do I need it? Is something else causing the lib to not be found? Thanks, Rick Knight From rick_knight at rlknight.com Wed Aug 6 13:17:55 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:17:55 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F8E3.5060400@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Thanks for the reply. The developer of the app I'm trying to use (Readerware) has sent me a copy of the comm.api and I've copied the library (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar into the proper places. When I try to run the application, I get this error... Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: /usr/lib/libSolarisSerialParallel.so: /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not little-endian (Possible cause: endianness mismatch) Caught java.lang.UnsatisfiedLinkError: com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I while loading driver com.sun.comm.SolarisDriver Is there a way around this error? Thanks again, Rick Knight From jlar310 at gmail.com Wed Aug 6 13:37:42 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 14:37:42 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899F8E3.5060400@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > The developer of the app I'm trying to use (Readerware) has sent me a > copy of the comm.api and I've copied the library > (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar > into the proper places. When I try to run the application, I get this > error... > > Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: > /usr/lib/libSolarisSerialParallel.so: > /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not > little-endian (Possible cause: endianness mismatch) > Caught java.lang.UnsatisfiedLinkError: > com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I > > while loading driver com.sun.comm.SolarisDriver > > Is there a way around this error? What host OS are you running? From your original post it looks like 32 bit Linux. The libSolarisSerialParallel.so file is for Sun Solaris and will vary depending on the underlying hardware architecture as well. Sorry for the double post Rick, but I failed to send this to the list the first time... -- Jeff From rick_knight at rlknight.com Wed Aug 6 13:44:29 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:44:29 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: <4899FF1D.9030504@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > > >> The developer of the app I'm trying to use (Readerware) has sent me a >> copy of the comm.api and I've copied the library >> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >> into the proper places. When I try to run the application, I get this >> error... >> >> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >> /usr/lib/libSolarisSerialParallel.so: >> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >> little-endian (Possible cause: endianness mismatch) >> Caught java.lang.UnsatisfiedLinkError: >> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >> >> while loading driver com.sun.comm.SolarisDriver >> >> Is there a way around this error? >> > > What host OS are you running? From your original post it looks like 32 > bit Linux. > > The libSolarisSerialParallel.so file is for Sun Solaris and will vary > depending on the underlying hardware architecture as well. > > I'm running Kubuntu Linux (debian based). It's 32 bit. Rick Knight From jlar310 at gmail.com Wed Aug 6 15:33:23 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 16:33:23 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > I don't think Sun did binary libraries for Linux in the 2.0 version. Can someone with more historical experience than I confirm that? I recently tried to port a Comm API application from Solaris sparc to Linux x86 and likewise could not get my hands on the binary libraries. I eventually just re-wrote the code to use the gnu namespace packages and rxtx 2.1. What I don't understand is why your application vendor does not provide everything you need to run their software. FYI: I have librxtxParallel.so and librxtxSerial.so installed at JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is /usr/java/default which is actually a softlink to /usr/java/jre1.6.0_05. -- Jeff From defiantlew at yahoo.com.au Wed Aug 6 16:29:33 2008 From: defiantlew at yahoo.com.au (Lew L) Date: Thu, 7 Aug 2008 08:29:33 +1000 Subject: [Rxtx] Sun's Comm API Documentation References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> Message-ID: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> As a matter of interest is the Sun Comm API documentation available somewhere? I have tried the Sun site but it seems to have been removed. Unless I have missed the documentation for RXTX? I javadocced the RXTX source but information (to me) is minimal. Somewhere I got the impression that the Sun Comm API docs is, or was, compatible with RXTX, what is the best docs to use in conjuntion with RXTX and where may the be available? Cheers Lew From rick_knight at rlknight.com Wed Aug 6 17:18:33 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:18:33 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A3149.4050306@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff I'm not sure if I posted this here or not, but when I try to build RXTX from source I get this install error... make all-am make[1]: Entering directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' make[1]: Nothing to be done for `all-am'. make[1]: Leaving directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 Can you tell me how to get past this error and get RXTX built and installed? Thanks, Rick From bboyes at systronix.com Wed Aug 6 17:40:12 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Wed, 06 Aug 2008 17:40:12 -0600 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: At 16:29 08/06/2008, Lew L wrote: >As a matter of interest is the Sun Comm API documentation available >somewhere? I have tried the Sun site but it seems to have been removed. It's in the file we have posted, link in prev email (sorry, in a huge hurry right now). Javadocs definitely there. >Unless I have missed the documentation for RXTX? I javadocced the RXTX >source but information (to me) is minimal. >Somewhere I got the impression that the Sun Comm API docs is, or was, >compatible with RXTX, what is the best docs to use in conjuntion with RXTX >and where may the be available? Yeah, this is one of my concerns/beefs. There is little documentation for RXTX and it isn't just the same as javaxcomm. I would be willing to help out writing docs for RXTX! Yes really... esp if we can fix the Bluetooth issues. best regards Bruce >Cheers >Lew > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx ------- WWW.SYSTRONIX.COM ---------- Real embedded Java and much more +1-801-534-1017 Salt Lake City, USA From rick_knight at rlknight.com Wed Aug 6 17:54:08 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:54:08 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A39A0.2090309@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff, I would like for my vendor to switch to rxtx 2.1. It would make things much easier for me. I'm not sure why he's still using the javax compatible code. He's a small operation. Re-writing the code to use gnu namespace sounds like a major overhaul. Was it? Thanks, Rick From tjarvi at qbang.org Wed Aug 6 21:35:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:35:12 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: >> >>> Jeff wrote: >>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>>> >>>> >>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things > much easier for me. I'm not sure why he's still using the javax > compatible code. He's a small operation. Re-writing the code to use gnu > namespace sounds like a major overhaul. Was it? > Hi Jeff, The changes are fairly mechanical. Imports need to change and any explicite use of the namespace needs to change such as catching an exception. The following script was made for maintaining rxtx 2.0 but can apply to other needs. It is in the contrib dir with rxtx source. #!/bin/sh # Don't use! :) # # Sat, 03 May 2003 16:45:08 Modifications from J?rg Weule # Create a ed-cmd for the change of one pattern # case $1 in gnu) X=g/javax_comm/s+javax_comm+gnu_io+g ;; javax) X=g/gnu_io/s+gnu_io+javax_comm+g ;; *) echo;echo;echo From the top rxtx directory run;echo;echo -e \\t./ChangePackage.sh gnu;echo -e \\t\\tor;echo -e \\t./ChangePackage.sh javax;echo;echo; exit 0 ;; esac # # ed will be used to keep the owner and mode of the files unchanged. # We have run the ed-script for the characters '.' '/' as well. # "tr _ $D" do the change. # find . -type f -a -print | grep -v $0 | (while read F ; do ( echo $X; echo $X| tr _ /; echo $X| tr _ .; echo w; echo q ) | ed $F 2>&1 >/dev/null done ) # # Now we do little changes at the Makefiles. Hope that all we need. # find . -name Makefile\* -a -print | (while read F ; do cat < References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: On Thu, 7 Aug 2008, Lew L wrote: > As a matter of interest is the Sun Comm API documentation available > somewhere? I have tried the Sun site but it seems to have been removed. > > Unless I have missed the documentation for RXTX? I javadocced the RXTX > source but information (to me) is minimal. > Somewhere I got the impression that the Sun Comm API docs is, or was, > compatible with RXTX, what is the best docs to use in conjuntion with RXTX > and where may the be available? > Hi Lew, The documentation on Sun's website is accurate. The changes that are problematic in 3.0 are on the backside which rxtx used to plug into. http://java.sun.com/products/javacomm/reference/api/index.html CommPortIdentifier may have some minor differences (judging by the authors notes). -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Aug 6 21:46:08 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:46:08 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > If javax.comm.properties is properly installed and you are using a 2.0 version of Sun's commapi with rxtx 2.0, you should not see the library attempt to load libSolarisSerialParallel.so. Sun CommAPI 3.0 will not work with any version of rxtx as it is hard coded to use the shared library. See the INSTALL file with rxtx-2.0 source for more help with the properties file. -- Trent Jarvi tjarvi at qbang.org From jlar310 at gmail.com Thu Aug 7 06:32:06 2008 From: jlar310 at gmail.com (Jeff) Date: Thu, 7 Aug 2008 07:32:06 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > Jeff wrote: >> >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >> wrote: >> >>> >>> Jeff wrote: >>> >>>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>> wrote: >>>> >>>> >>>> >>>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things much > easier for me. I'm not sure why he's still using the javax compatible code. > He's a small operation. Re-writing the code to use gnu namespace sounds like > a major overhaul. Was it? I found it quite easy. In fact, in order to accommodate the transition, I actually separated all of the code that deals directly with the Comm API or RXTX into a helper class. The helper class was then coded to use reflection to determine which library was available and then instantiate the necessary objects. No direct imports of either library are used. The main application just needs to get it's hands on the IO streams and need not deal directly with the libraries. Other programs may not be so simple... But this doesn't really help you unless your vendor forks over the source code... -- Jeff From rick_knight at rlknight.com Thu Aug 7 09:47:12 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Thu, 07 Aug 2008 08:47:12 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: <489B1900.10108@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >>> wrote: >>> >>> >>>> Jeff wrote: >>>> >>>> >>>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>>> copy of the comm.api and I've copied the library >>>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>>> into the proper places. When I try to run the application, I get this >>>>>> error... >>>>>> >>>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>>> /usr/lib/libSolarisSerialParallel.so: >>>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>>> little-endian (Possible cause: endianness mismatch) >>>>>> Caught java.lang.UnsatisfiedLinkError: >>>>>> >>>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>>> >>>>>> while loading driver com.sun.comm.SolarisDriver >>>>>> >>>>>> Is there a way around this error? >>>>>> >>>>>> >>>>>> >>>>> What host OS are you running? From your original post it looks like 32 >>>>> bit Linux. >>>>> >>>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>>> depending on the underlying hardware architecture as well. >>>>> >>>>> >>>>> >>>>> >>>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>>> >>>> >>>> >>> I don't think Sun did binary libraries for Linux in the 2.0 version. >>> Can someone with more historical experience than I confirm that? >>> >>> I recently tried to port a Comm API application from Solaris sparc to >>> Linux x86 and likewise could not get my hands on the binary libraries. >>> I eventually just re-wrote the code to use the gnu namespace packages >>> and rxtx 2.1. >>> >>> What I don't understand is why your application vendor does not >>> provide everything you need to run their software. >>> >>> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >>> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >>> /usr/java/default which is actually a softlink to >>> /usr/java/jre1.6.0_05. >>> >>> >>> >> Jeff, >> >> I would like for my vendor to switch to rxtx 2.1. It would make things much >> easier for me. I'm not sure why he's still using the javax compatible code. >> He's a small operation. Re-writing the code to use gnu namespace sounds like >> a major overhaul. Was it? >> > > I found it quite easy. In fact, in order to accommodate the > transition, I actually separated all of the code that deals directly > with the Comm API or RXTX into a helper class. The helper class was > then coded to use reflection to determine which library was available > and then instantiate the necessary objects. No direct imports of > either library are used. The main application just needs to get it's > hands on the IO streams and need not deal directly with the libraries. > Other programs may not be so simple... > > But this doesn't really help you unless your vendor forks over the > source code... > > Jeff, This may not help me directly, but I'm going to forward this thread to the vendor. I think he'll be open to making things work. Thanks again, Rick Knight From agusmunioz at gmail.com Thu Aug 7 16:39:51 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Thu, 7 Aug 2008 19:39:51 -0300 Subject: [Rxtx] How to send ack? Message-ID: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Hi, I'm still learning about serial communication and I have some doubts. I've got this question about how to do the following thing in rxtx. I have this hardware that connect to a PC using a serial port. These hardware receives data from a telephone line, proccess it, and then send it forward to the serial port. I've used a program named wincomm that shows what information is send it through the serial port and I have the nex behaviour: The hardware has a buffer where all data is stored, that cannot be sent it through the seria port. The program reads the first data send it by the hardware, and keep reading the same data always. There is a button in the application that says enable Ack, and when I click, then the hardware start to send all the stored information, and all the information is shown. I write a class, using rxtx that reads the serial port, and the same thing happens, it remains reading the same (first) data all the time. And I thing something like the enable Ack I'm missing. How can I do this enable Ack from my java code using rxtx? Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080807/e0a0f9a1/attachment-0022.html From ajmas at sympatico.ca Thu Aug 7 18:26:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 7 Aug 2008 20:26:41 -0400 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: <4BF42297-81E2-4BB8-A89F-1D43588379AE@sympatico.ca> On 6-Aug-08, at 19:40 , Bruce Boyes wrote: >> Unless I have missed the documentation for RXTX? I javadocced the >> RXTX >> source but information (to me) is minimal. >> Somewhere I got the impression that the Sun Comm API docs is, or was, >> compatible with RXTX, what is the best docs to use in conjuntion >> with RXTX >> and where may the be available? > > Yeah, this is one of my concerns/beefs. There is little documentation > for RXTX and it isn't just the same as javaxcomm. > > I would be willing to help out writing docs for RXTX! Yes really... > esp if we can fix the Bluetooth issues. If you want to contribute documentation then the best place to do that is the wiki. If there is anything missing or that could be improved on then please do so. If there are any points that you would like to see improved, for which you don't have the knowledge then ask on the mailing list for a volunteer. Andre From florianmanschwetus at gmx.de Fri Aug 8 03:04:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Fri, 08 Aug 2008 11:04:14 +0200 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Message-ID: <489C0C0E.2020401@gmx.de> Agustin Mu?oz schrieb: > Hi, I'm still learning about serial communication and I have some > doubts. I've got this question about how to do the following thing in rxtx. > I have this hardware that connect to a PC using a serial port. These > hardware receives data from a telephone line, proccess it, and then send > it forward to the serial port. I've used a program named wincomm that > shows what information is send it through the serial port and I have the > nex behaviour: > > The hardware has a buffer where all data is stored, that cannot be sent > it through the seria port. > The program reads the first data send it by the hardware, and keep > reading the same data always. > There is a button in the application that says enable Ack, and when I > click, then the hardware start to send all the stored information, and > all the information is shown. > > I write a class, using rxtx that reads the serial port, and the same > thing happens, it remains reading the same (first) data all the time. > And I thing something like the enable Ack I'm missing. > How can I do this enable Ack from my java code using rxtx? Afaik, a look at man ascii reveals: Okt Dez Hex Char 006 6 06 ACK So, i hope this will do the job: send(6); florian > > Thanks in advance > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/5b4965f8/attachment-0022.bin From agusmunioz at gmail.com Fri Aug 8 16:31:00 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 19:31:00 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <489C0C0E.2020401@gmx.de> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> Message-ID: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Hi Florian, thanks for the answer. By send(6) you mean to get the port OutputStream and write a 6? I try that but it didn't work. Any suggestion? Thanks On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < florianmanschwetus at gmx.de> wrote: > Agustin Mu?oz schrieb: > > Hi, I'm still learning about serial communication and I have some doubts. >> I've got this question about how to do the following thing in rxtx. >> I have this hardware that connect to a PC using a serial port. These >> hardware receives data from a telephone line, proccess it, and then send it >> forward to the serial port. I've used a program named wincomm that shows >> what information is send it through the serial port and I have the nex >> behaviour: >> >> The hardware has a buffer where all data is stored, that cannot be sent >> it through the seria port. >> The program reads the first data send it by the hardware, and keep reading >> the same data always. >> There is a button in the application that says enable Ack, and when I >> click, then the hardware start to send all the stored information, and all >> the information is shown. >> >> I write a class, using rxtx that reads the serial port, and the same thing >> happens, it remains reading the same (first) data all the time. And I thing >> something like the enable Ack I'm missing. >> How can I do this enable Ack from my java code using rxtx? >> > Afaik, a look at man ascii reveals: > Okt Dez Hex Char > 006 6 06 ACK > So, i hope this will do the job: > send(6); > > florian > >> >> Thanks in advance >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/7f3fba42/attachment-0021.html From agusmunioz at gmail.com Fri Aug 8 18:39:27 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 21:39:27 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Message-ID: <988288430808081739x7f9e7889id82591d5a9e2b4f6@mail.gmail.com> Ok, Florian, it works!! my problem was that I've been sending, through the OutputStream, the bytes of 6 as a string: out.write("6".getBytes()); but then I realized that you can write an int on an OuptuStream, so I tried that and It works: out.write(6); Thank you for the guidance!! On Fri, Aug 8, 2008 at 7:31 PM, Agustin Mu?oz wrote: > Hi Florian, thanks for the answer. By send(6) you mean to get the port > OutputStream and write a 6? > > I try that but it didn't work. > > Any suggestion? > > Thanks > > > On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < > florianmanschwetus at gmx.de> wrote: > >> Agustin Mu?oz schrieb: >> >> Hi, I'm still learning about serial communication and I have some doubts. >>> I've got this question about how to do the following thing in rxtx. >>> I have this hardware that connect to a PC using a serial port. These >>> hardware receives data from a telephone line, proccess it, and then send it >>> forward to the serial port. I've used a program named wincomm that shows >>> what information is send it through the serial port and I have the nex >>> behaviour: >>> >>> The hardware has a buffer where all data is stored, that cannot be sent >>> it through the seria port. >>> The program reads the first data send it by the hardware, and keep >>> reading the same data always. >>> There is a button in the application that says enable Ack, and when I >>> click, then the hardware start to send all the stored information, and all >>> the information is shown. >>> >>> I write a class, using rxtx that reads the serial port, and the same >>> thing happens, it remains reading the same (first) data all the time. And I >>> thing something like the enable Ack I'm missing. >>> How can I do this enable Ack from my java code using rxtx? >>> >> Afaik, a look at man ascii reveals: >> Okt Dez Hex Char >> 006 6 06 ACK >> So, i hope this will do the job: >> send(6); >> >> florian >> >>> >>> Thanks in advance >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/b918ab3d/attachment-0021.html From florianmanschwetus at gmx.de Sat Aug 9 00:45:43 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Sat, 09 Aug 2008 08:45:43 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4899667C.6010706@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> Message-ID: <489D3D17.9090209@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >> Florian Manschwetus wrote: >>> Ok, sounds fine for the receiving problem. >>> But why i have to wait after each byte when sending a command squence? >>> (the for loop in send command) >> >> Hi Florian, >> I'd imagine you probably don't! You could send all bytes in one go and >> RXTX would send them. The problem is most probably the other end: >> perhaps it has a really small buffer, some non-standard UART, or a >> crazy timing issue. If you attach a terminal to your output and send >> all the bytes of a command in one go they should appear no problem. >> >> Regards, >> Michael Erskine. >> > correct with a terminal on the other end it works, my idea was that this > basic baud has some influence. Could some one explain what it is for? > > Florian To make it more clear, my problem is that i can't use: outputStream.write(byte[]); => Beamer doesn't understand the sequence. (mostly no answer when he answers then *001) when i use this construct instead: for (int i = 0; i < command.length; i++) { this.outputStream.write(command[i]); try { Thread.sleep(25); } catch (InterruptedException e) { // TODO Auto-generated catch block e.printStackTrace(); } } it works nearly reliable. So what could it be? This Basic Baud is what exactly? Florian -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080809/692304ee/attachment-0021.bin From tjarvi at qbang.org Sat Aug 9 16:37:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Aug 2008 16:37:19 -0600 (MDT) Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489D3D17.9090209@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> <489D3D17.9090209@gmx.de> Message-ID: On Sat, 9 Aug 2008, Florian Manschwetus wrote: > Florian Manschwetus schrieb: >> Michael Erskine schrieb: >>> Florian Manschwetus wrote: >>>> Ok, sounds fine for the receiving problem. >>>> But why i have to wait after each byte when sending a command squence? >>>> (the for loop in send command) >>> >>> Hi Florian, >>> I'd imagine you probably don't! You could send all bytes in one go and >>> RXTX would send them. The problem is most probably the other end: perhaps >>> it has a really small buffer, some non-standard UART, or a crazy timing >>> issue. If you attach a terminal to your output and send all the bytes of a >>> command in one go they should appear no problem. >>> >>> Regards, >>> Michael Erskine. >>> >> correct with a terminal on the other end it works, my idea was that this >> basic baud has some influence. Could some one explain what it is for? >> >> Florian > To make it more clear, > my problem is that i can't use: > outputStream.write(byte[]); > => Beamer doesn't understand the sequence. (mostly no answer when he answers > then *001) > > when i use this construct instead: > > for (int i = 0; i < command.length; i++) { > this.outputStream.write(command[i]); > try { > Thread.sleep(25); > } catch (InterruptedException e) { > // TODO Auto-generated catch block > e.printStackTrace(); > } > } > > it works nearly reliable. > > So what could it be? This Basic Baud is what exactly? > I suspect you are using the 'moon protocol' and don't know it. RXTX enables this by default. The buffer on the other end is first in first out while reading. If the buffer is full, the bits are hand carried to the moon and burried. Then if the other side reads a couple bytes, two more bytes go into the buffer followed by more moon protocol. The resulting array of bytes the other side reads may appear to be scrambled until you go to the moon, get the bits and insert them in the right place. Flow control can prevent the default moon protocol and throttles the communiation by almost writing a byte at a time as need be. Hardware flow control is preferable but software flow control should also work. Read and write can appear to hang if the other side is not connected. This is why we don't enable them all the time. If you can't use flow control, you have to take care with the moon protocol and give the other side time to read. That is what your slower version of write is doing. -- Trent Jarvi tjarvi at qbang.org From rxtx at allenjb.me.uk Mon Aug 11 08:06:36 2008 From: rxtx at allenjb.me.uk (AllenJB) Date: Mon, 11 Aug 2008 15:06:36 +0100 Subject: [Rxtx] Disabling EV_RXFLAG Message-ID: <48A0476C.2090800@allenjb.me.uk> Hi all, I'm working with a device which does not use an EvtChar and need to disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an event mask of FD 01 00 00. The reference software I have uses FB 00 00 00. With the rxtx mask I get framing errors which I believe are caused when the EvtChar is received. Is there currently a way with rxtx (I've using rxtx from Java) to disable EV_RXFLAG? If not from Java, where would I start if I wanted to turn the EV_RXFLAG option off in the C code? I've had a grep of the rxtx source code, but I can't see where EV_RXFLAG is being set. Thanks in advance, AllenJB From tjarvi at qbang.org Mon Aug 11 14:17:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Aug 2008 14:17:27 -0600 (MDT) Subject: [Rxtx] Disabling EV_RXFLAG In-Reply-To: <48A0476C.2090800@allenjb.me.uk> References: <48A0476C.2090800@allenjb.me.uk> Message-ID: On Mon, 11 Aug 2008, AllenJB wrote: > Hi all, > > I'm working with a device which does not use an EvtChar and need to > disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an > event mask of FD 01 00 00. The reference software I have uses FB 00 00 > 00. With the rxtx mask I get framing errors which I believe are caused > when the EvtChar is received. > > Is there currently a way with rxtx (I've using rxtx from Java) to > disable EV_RXFLAG? > > If not from Java, where would I start if I wanted to turn the EV_RXFLAG > option off in the C code? I've had a grep of the rxtx source code, but I > can't see where EV_RXFLAG is being set. > > Thanks in advance, > > AllenJB Hi Allen, I'd look at termios.c::tcsetattr() and termios.c::FillDCB() -- Trent Jarvi tjarvi at qbang.org From superdadusa at gmail.com Tue Aug 12 13:57:32 2008 From: superdadusa at gmail.com (John Choi) Date: Tue, 12 Aug 2008 13:57:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. Message-ID: Hi all, Just let you all know I just start to learn Java. I have download the serial comm package and the source code from open source communities.. I was able to verify with the given message string via serial monitor. when the given message string sends to the serial port then the character return added to the end of string by default if I use "Hello World" however if I changed to something else other than "Hello, World" there is no character return add to the end of string. I thing the library download from rxtx.org has implemented for the special strings. I can do like "login\n" in the string message to make character return but I don't want to add this individual custom character for each command return in every static message string I send, Can any who have done this might help me? Basically, something like this,, Write and add function to the program write a command, Reads the respond from a serial device.. Function handles multiple messages, Write: "com open" Read: Welcome to my world" expected Write: "admin" Read: Password?, expected Write: "admin" Read: you are successfully login terminal, expected. And I need to add a separate function handler handles a character return add to the each command above. If anyone can help this I can do the reset? Thank you in advance, John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0017.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SerialIO.java Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0017.pl From Steffen.DETTMER at ingenico.com Wed Aug 13 02:16:38 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 13 Aug 2008 10:16:38 +0200 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: References: Message-ID: <20080813081638.GA25412@elberon.bln.de.ingenico.com> * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > I can do like "login\n" in the string message to make character > return but I don't want to add this individual custom character > for each command return in every static message string I send, and why not?! > Can any who have done this might help me? what's about with writing a small wrapper function adding the carriage return? However, this would be slow, because either you call write two times (very bad) or the string needs to be copied, \n appended and written (since you are using Java Performance probably isn't so critical). Personally I would write `"login\n"' and `username + "\n"' etc., because since it is part of the command it should be part of the command definition string. > Basically, something like this,, Write and add function to the program write > a command, Reads the respond from a serial device.. correctly reading a `line' is more difficult. If you cannot make assumptions about timeouts and/or you need to have low delay, you need to read byte wise. If you need to save CPU resources you might need to add some buffering layer that you can read byte-wise but that is reading blockwise with some small timeout (lets say for serial lines something around byte transmission time times three or so). > /* > * To change this template, choose Tools | Templates > * and open the template in the editor. > */ :) > package joliba; > > /** > * > * @author root > */ :) > // derived from SUN's examples in the javax.comm package > import java.io.*; > import java.util.*; > //import javax.comm.*; // for SUN's serial/parallel port libraries > import gnu.io.*; // for rxtxSerial library > > public class SerialIO implements Runnable, SerialPortEventListener { > static CommPortIdentifier portId; > static CommPortIdentifier saveportId; > static Enumeration portList; > InputStream inputStream; > SerialPort serialPort; > Thread readThread; You need a thread for your synchronous RPC-style protocol? > static String messageString = "Hello, world!"; > static OutputStream outputStream; > static boolean outputBufferEmptyFlag = false; > > public static void main(String[] args) { > boolean portFound = false; > String defaultPort; > > // determine the name of the serial port on several operating systems > String osname = System.getProperty("os.name","").toLowerCase(); > if ( osname.startsWith("windows") ) { > // windows > defaultPort = "COM1"; > } else if (osname.startsWith("linux")) { > // linux > defaultPort = "/dev/ttyS0"; > } else if ( osname.startsWith("mac") ) { > // mac > defaultPort = "????"; > } else { > System.out.println("Sorry, your operating system is not supported"); > return; > } Is such a construction recommended? Isn't there some abstraction (like COM1 working on any platform)? [...] > try { > // activate the OUTPUT_BUFFER_EMPTY notifier > serialPort.notifyOnOutputEmpty(true); > } catch (Exception e) { > System.out.println("Error setting event notification"); > System.out.println(e.toString()); > System.exit(-1); > } I doubt that -1 is defined, probably some 127 or so would be the result, maybe better simply `throw e'? > public void writetoport() { > System.out.println("Writing \""+messageString+"\" to "+serialPort.getName()); > try { > // write string to serial port > outputStream.write(messageString.getBytes()); > } catch (IOException e) {} > } maybe something like /** * Writes the given output string and an additional carriage * return to the current outputStream. */ public void writeStringToPort( /** The output string (without CR). */ String output ) throws IOException { String outputLine = output + "\n"; outputStream.write(outputLine.getBytes()); } ? > > public SerialIO() { > // initalize serial port > try { > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > } catch (PortInUseException e) {} if the port is in use, you continue? Wonder that this works in Java, I would assume serialPort beeing uninitialized which AFAIK is an error in Java. > try { > inputStream = serialPort.getInputStream(); > } catch (IOException e) {} > > try { > serialPort.addEventListener(this); > } catch (TooManyListenersException e) {} > > // activate the DATA_AVAILABLE notifier > serialPort.notifyOnDataAvailable(true); > > try { > // set port parameters > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > } catch (UnsupportedCommOperationException e) {} > > // start the read thread > readThread = new Thread(this); > readThread.start(); > > } I think in all those exception cases you can abort, because it is unlikely that ignoring those errors allow a successful continuation, so in this case maybe it would be better to add a throw clause to the method. > public void run() { > // first thing in the thread, we initialize the write operation > initwritetoport(); > try { > while (true) { > // write string to port, the serialEvent will read it > writetoport(); > Thread.sleep(1000); > } > } catch (InterruptedException e) {} > } Does this make sense? Your `SimpleReadApp' writes one and the same string each second? > public void serialEvent(SerialPortEvent event) { > switch (event.getEventType()) { > case SerialPortEvent.BI: > case SerialPortEvent.OE: > case SerialPortEvent.FE: > case SerialPortEvent.PE: > case SerialPortEvent.CD: > case SerialPortEvent.CTS: > case SerialPortEvent.DSR: > case SerialPortEvent.RI: > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > break; > case SerialPortEvent.DATA_AVAILABLE: > // we get here if data has been received > byte[] readBuffer = new byte[20]; > try { > // read data > while (inputStream.available() > 0) { > int numBytes = inputStream.read(readBuffer); > } > // print data > String result = new String(readBuffer); > System.out.println("Read: "+result); > } catch (IOException e) {} I doubt that this is correct. I would assume you will get a 20 bytes result always, if more bytes would be available they would be printed in a second line but if less bytes are read I'd assume that the buffer/result contains zero bytes from implicite readBuffer contents initialisation (zero is no string terminator in Java AFAIK). > break; > } > } > } oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From florianmanschwetus at gmx.de Wed Aug 13 06:09:31 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 13 Aug 2008 14:09:31 +0200 Subject: [Rxtx] someone has seen such errors? Message-ID: <48A2CEFB.90007@gmx.de> I mean my communication mostly works, but it is far from perfect could this be the reason? Florian Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/949b9947/attachment-0017.bin From superdadusa at gmail.com Wed Aug 13 08:40:32 2008 From: superdadusa at gmail.com (John Choi) Date: Wed, 13 Aug 2008 08:40:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: <20080813081638.GA25412@elberon.bln.de.ingenico.com> References: <20080813081638.GA25412@elberon.bln.de.ingenico.com> Message-ID: Thank you so much Steffen and I will try that suggestion. John On 8/13/08, Steffen DETTMER wrote: > > * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > > I can do like "login\n" in the string message to make character > > return but I don't want to add this individual custom character > > for each command return in every static message string I send, > > and why not?! > > > Can any who have done this might help me? > > what's about with writing a small wrapper function adding the > carriage return? > However, this would be slow, because either you call write two > times (very bad) or the string needs to be copied, \n appended > and written (since you are using Java Performance probably isn't > so critical). > > Personally I would write `"login\n"' and `username + "\n"' etc., > because since it is part of the command it should be part of the > command definition string. > > > Basically, something like this,, Write and add function to the program > write > > a command, Reads the respond from a serial device.. > > correctly reading a `line' is more difficult. If you cannot make > assumptions about timeouts and/or you need to have low delay, you > need to read byte wise. If you need to save CPU resources you > might need to add some buffering layer that you can read > byte-wise but that is reading blockwise with some small timeout > (lets say for serial lines something around byte transmission > time times three or so). > > > /* > > * To change this template, choose Tools | Templates > > * and open the template in the editor. > > */ > > :) > > > package joliba; > > > > /** > > * > > * @author root > > */ > > :) > > > // derived from SUN's examples in the javax.comm package > > import java.io.*; > > import java.util.*; > > //import javax.comm.*; // for SUN's serial/parallel port libraries > > import gnu.io.*; // for rxtxSerial library > > > > public class SerialIO implements Runnable, SerialPortEventListener { > > static CommPortIdentifier portId; > > static CommPortIdentifier saveportId; > > static Enumeration portList; > > InputStream inputStream; > > SerialPort serialPort; > > Thread readThread; > > You need a thread for your synchronous RPC-style protocol? > > > static String messageString = "Hello, world!"; > > static OutputStream outputStream; > > static boolean outputBufferEmptyFlag = false; > > > > public static void main(String[] args) { > > boolean portFound = false; > > String defaultPort; > > > > // determine the name of the serial port on several operating > systems > > String osname = System.getProperty("os.name","").toLowerCase(); > > if ( osname.startsWith("windows") ) { > > // windows > > defaultPort = "COM1"; > > } else if (osname.startsWith("linux")) { > > // linux > > defaultPort = "/dev/ttyS0"; > > } else if ( osname.startsWith("mac") ) { > > // mac > > defaultPort = "????"; > > } else { > > System.out.println("Sorry, your operating system is not > supported"); > > return; > > } > > Is such a construction recommended? Isn't there some abstraction > (like COM1 working on any platform)? > > [...] > > try { > > // activate the OUTPUT_BUFFER_EMPTY notifier > > serialPort.notifyOnOutputEmpty(true); > > } catch (Exception e) { > > System.out.println("Error setting event notification"); > > System.out.println(e.toString()); > > System.exit(-1); > > } > > I doubt that -1 is defined, probably some 127 or so would be the > result, maybe better simply `throw e'? > > > public void writetoport() { > > System.out.println("Writing \""+messageString+"\" to > "+serialPort.getName()); > > try { > > // write string to serial port > > outputStream.write(messageString.getBytes()); > > } catch (IOException e) {} > > } > > maybe something like > > /** > * Writes the given output string and an additional carriage > * return to the current outputStream. > */ > public void > writeStringToPort( > /** The output string (without CR). */ > String output > ) throws IOException > { > String outputLine = output + "\n"; > outputStream.write(outputLine.getBytes()); > } > > ? > > > > > public SerialIO() { > > // initalize serial port > > try { > > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > > } catch (PortInUseException e) {} > > if the port is in use, you continue? Wonder that this works in > Java, I would assume serialPort beeing uninitialized which AFAIK > is an error in Java. > > > try { > > inputStream = serialPort.getInputStream(); > > } catch (IOException e) {} > > > > try { > > serialPort.addEventListener(this); > > } catch (TooManyListenersException e) {} > > > > // activate the DATA_AVAILABLE notifier > > serialPort.notifyOnDataAvailable(true); > > > > try { > > // set port parameters > > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > } catch (UnsupportedCommOperationException e) {} > > > > // start the read thread > > readThread = new Thread(this); > > readThread.start(); > > > > } > > I think in all those exception cases you can abort, because it is > unlikely that ignoring those errors allow a successful > continuation, so in this case maybe it would be better to add a > throw clause to the method. > > > public void run() { > > // first thing in the thread, we initialize the write operation > > initwritetoport(); > > try { > > while (true) { > > // write string to port, the serialEvent will read it > > writetoport(); > > Thread.sleep(1000); > > } > > } catch (InterruptedException e) {} > > } > > Does this make sense? Your `SimpleReadApp' writes one and the > same string each second? > > > public void serialEvent(SerialPortEvent event) { > > switch (event.getEventType()) { > > case SerialPortEvent.BI: > > case SerialPortEvent.OE: > > case SerialPortEvent.FE: > > case SerialPortEvent.PE: > > case SerialPortEvent.CD: > > case SerialPortEvent.CTS: > > case SerialPortEvent.DSR: > > case SerialPortEvent.RI: > > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > > break; > > case SerialPortEvent.DATA_AVAILABLE: > > // we get here if data has been received > > byte[] readBuffer = new byte[20]; > > try { > > // read data > > while (inputStream.available() > 0) { > > int numBytes = inputStream.read(readBuffer); > > } > > // print data > > String result = new String(readBuffer); > > System.out.println("Read: "+result); > > } catch (IOException e) {} > > I doubt that this is correct. I would assume you will get a 20 > bytes result always, if more bytes would be available they would > be printed in a second line but if less bytes are read I'd assume > that the buffer/result contains zero bytes from implicite > readBuffer contents initialisation (zero is no string terminator > in Java AFAIK). > > > break; > > } > > } > > } > > oki, > > Steffen > > About Ingenico Throughout the world businesses rely on Ingenico for secure > and expedient electronic transaction acceptance. Ingenico products leverage > proven technology, established standards and unparalleled ergonomics to > provide optimal reliability, versatility and usability. This comprehensive > range of products is complemented by a global array of services and > partnerships, enabling businesses in a number of vertical sectors to accept > transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged > information. If you are not the addressee or authorized to receive this for > the addressee, you must not use, copy, disclose or take any action based on > this message or any information herein. If you have received this message in > error, please advise the sender immediately by reply e-mail and delete this > message. Thank you for your cooperation. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/73c4135c/attachment-0016.html From ajmas at sympatico.ca Sat Aug 16 07:15:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 09:15:41 -0400 Subject: [Rxtx] someone has seen such errors? In-Reply-To: <48A2CEFB.90007@gmx.de> References: <48A2CEFB.90007@gmx.de> Message-ID: <43B5E8DA-1D93-4D90-809B-AAF35FF724C5@sympatico.ca> On 13-Aug-08, at 08:09 , Florian Manschwetus wrote: > I mean my communication mostly works, but it is far from perfect > could this be the reason? > > Florian > > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control Judging by the error messages this looks related to the driver you are using. Do a search for the following string with you favourite search engine, it should turn up a few hits: ftdi_set_termios FAILED to set databits/stopbits/parity Andre From ajmas at sympatico.ca Sat Aug 16 19:12:04 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 21:12:04 -0400 Subject: [Rxtx] Using SerialPortEvent? Message-ID: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Hi, Could someone tell me how I should be using the SerialPortEvent? Am I meant to be waiting for data and then simply reading from the inputstream? If this is the case why no just block on an inputstream read? Andr? From tjarvi at qbang.org Sat Aug 16 19:41:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 16 Aug 2008 19:41:13 -0600 (MDT) Subject: [Rxtx] Using SerialPortEvent? In-Reply-To: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> References: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Message-ID: On Sat, 16 Aug 2008, Andre-John Mas wrote: > Hi, > > Could someone tell me how I should be using the SerialPortEvent? Am I > meant to be waiting for data and then simply reading from the > inputstream? If this is the case why no just block on an inputstream > read? > Polling for data is fine also. It really depends upon what you are trying to do. For instance, if you require x bytes before reading, you can start polling after data is available. If you read on the same thread as your GUI and are waiting for data in a read, the results may be less than desirable. Java programming is 'usually' event driven rather than polling based. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sat Aug 16 20:10:39 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 22:10:39 -0400 Subject: [Rxtx] Using SerialPortEvent? In-Reply-To: References: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Message-ID: <3E495D4C-BB28-4845-A6AB-984C9A826BDF@sympatico.ca> On 16-Aug-08, at 21:41 , Trent Jarvi wrote: > On Sat, 16 Aug 2008, Andre-John Mas wrote: > >> Hi, >> >> Could someone tell me how I should be using the SerialPortEvent? Am I >> meant to be waiting for data and then simply reading from the >> inputstream? If this is the case why no just block on an inputstream >> read? >> > > Polling for data is fine also. It really depends upon what you are > trying to do. For instance, if you require x bytes before reading, > you can start polling after data is available. If you read on the > same thread as your GUI and are waiting for data in a read, the > results may be less than desirable. > > Java programming is 'usually' event driven rather than polling based. Sounds good. I thought I would use this opportunity to provide a event based version of the TwoWaySerialComm example. Could you just validate it before I add it to the Wiki: package ajmas74.experimental; import gnu.io.CommPort; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; import gnu.io.SerialPortEvent; import gnu.io.SerialPortEventListener; import java.io.IOException; import java.io.InputStream; import java.io.OutputStream; /** * This version of the TwoWaySerialComm example makes use of the * SerialPortEventListener to avoid polling. * * @author ajmas * */ public class TwoWaySerialComm { public TwoWaySerialComm() { super(); } void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { CommPort commPort = portIdentifier.open(this.getClass().getName(),2000); if ( commPort instanceof SerialPort ) { SerialPort serialPort = (SerialPort) commPort; serialPort .setSerialPortParams (57600 ,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); (new Thread(new SerialWriter(out))).start(); serialPort.addEventListener(new SerialReader(in)); } else { System.out.println("Error: Only serial ports are handled by this example."); } } } /** * Handles the input coming from the serial port. A new line character * is treated as the end of a block in this example. */ public static class SerialReader implements SerialPortEventListener { private InputStream in; private byte[] buffer = new byte[1024]; public SerialReader ( InputStream in ) { this.in = in; } public void serialEvent(SerialPortEvent arg0) { int data; try { int len = 0; while ( ( data = in.read()) > -1 ) { if ( data != '\n' ) { break; } buffer[len++] = (byte) data; } System.out.print(new String(buffer,0,len)); } catch ( IOException e ) { e.printStackTrace(); System.exit(-1); } } } /** */ public static class SerialWriter implements Runnable { OutputStream out; public SerialWriter ( OutputStream out ) { this.out = out; } public void run () { try { int c = 0; while ( ( c = System.in.read()) > -1 ) { this.out.write(c); } } catch ( IOException e ) { e.printStackTrace(); System.exit(-1); } } } public static void main ( String[] args ) { try { (new TwoWaySerialComm()).connect("COM3"); } catch ( Exception e ) { e.printStackTrace(); } } } From lfarkas at lfarkas.org Tue Aug 19 07:32:59 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Tue, 19 Aug 2008 15:32:59 +0200 Subject: [Rxtx] JNI or CNI Message-ID: <48AACB8B.9060606@lfarkas.org> hi, what is the current recommended way to rxtx on linux JNI or it's better to use CNI? is the CNI version fully functional and the same level as the JNI? i currently try to make a rhel/centos/fedora rpm for rxtx but has many problems with the standard dir structure. yours. -- Levente "Si vis pacem para bellum!" From lfarkas at lfarkas.org Tue Aug 19 08:47:34 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Tue, 19 Aug 2008 16:47:34 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel Message-ID: <48AADD06.7040809@lfarkas.org> hi, newer or not so newer linux kernel do not contain the UTS_RELEASE so the current rxtx is not compile on the latest kernels. even if it's commented out in the cvs configure there are other places. i attcahed a patch which fix it (or at least doesn't cause error at non-debug build). ps. is there any plan to the new 2.1-8 release in the near future? there are many changes (at least the license change in all file and in this case create a diff is very difficult)? the latest release more then 2 years old:-( -- Levente "Si vis pacem para bellum!" -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-2.1-uts.patch Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080819/ab5d38ac/attachment-0010.pl From ajmas at sympatico.ca Tue Aug 19 16:21:53 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 19 Aug 2008 18:21:53 -0400 Subject: [Rxtx] Event based example Message-ID: <24735BFB-B088-4B84-8173-FE98DF63B12F@sympatico.ca> Hi, I have just posted an example of using SerialPortEventListener in the Wiki: http://rxtx.qbang.org/wiki/index.php/Event_Based_Two_Way_Communication If you see any issues please could you let me know, or makes the changes. Andre From Martin.Oberhuber at windriver.com Fri Aug 22 04:02:24 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 22 Aug 2008 12:02:24 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <48AADD06.7040809@lfarkas.org> References: <48AADD06.7040809@lfarkas.org> Message-ID: <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> Farkas, there are indeed efforts to get a new RXTX release out the door. Your experience as a package maintainer would likely be helpful during these efforts, since I'd think it makes sense to keep the patches minimal that you must make to have the source compile in your environment. What are the things that you find problematic, apart from the UTS thing that you have mentioned before? What is the timing that you have in mind for your package? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Farkas Levente > Sent: Tuesday, August 19, 2008 4:48 PM > To: rxtx at qbang.org > Subject: [Rxtx] UTS_RELEASE not defined in newer kernel > > hi, > newer or not so newer linux kernel do not contain the > UTS_RELEASE so the > current rxtx is not compile on the latest kernels. even if it's > commented out in the cvs configure there are other places. > i attcahed a patch which fix it (or at least doesn't cause error at > non-debug build). > > ps. is there any plan to the new 2.1-8 release in the near > future? there > are many changes (at least the license change in all file and in this > case create a diff is very difficult)? the latest release more then 2 > years old:-( > > -- > Levente "Si vis pacem para bellum!" > From lfarkas at lfarkas.org Fri Aug 22 04:36:26 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Fri, 22 Aug 2008 12:36:26 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> References: <48AADD06.7040809@lfarkas.org> <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> Message-ID: <48AE96AA.6090505@lfarkas.org> hi, the packages already build for fedora-9 and centos-5 and here: http://www.lfarkas.org/linux/packages/ what i've to patch, the UTS, the configure script, but it's already fixed in the cvs (in another way) and the loadlibrary. the reasons for last one can be found here: https://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_files_that_use_JNI after we test it i'd like to add these packages to fedora and epel main repository (that's why it's be useful a new release after 2 years:-) imho versions are cheap and why not just release 2.1-8? the real code changes are minimal and if something critical bug found still can release 2.1-9:-) ps. and would be better to use simple number for version like 2.1-7 rather then 2.1-7v2. Oberhuber, Martin wrote: > Farkas, > > there are indeed efforts to get a new RXTX release out the > door. Your experience as a package maintainer would likely > be helpful during these efforts, since I'd think it makes > sense to keep the patches minimal that you must make to > have the source compile in your environment. > > What are the things that you find problematic, apart from > the UTS thing that you have mentioned before? > > What is the timing that you have in mind for your package? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >> On Behalf Of Farkas Levente >> Sent: Tuesday, August 19, 2008 4:48 PM >> To: rxtx at qbang.org >> Subject: [Rxtx] UTS_RELEASE not defined in newer kernel >> >> hi, >> newer or not so newer linux kernel do not contain the >> UTS_RELEASE so the >> current rxtx is not compile on the latest kernels. even if it's >> commented out in the cvs configure there are other places. >> i attcahed a patch which fix it (or at least doesn't cause error at >> non-debug build). >> >> ps. is there any plan to the new 2.1-8 release in the near >> future? there >> are many changes (at least the license change in all file and in this >> case create a diff is very difficult)? the latest release more then 2 >> years old:-( >> >> -- >> Levente "Si vis pacem para bellum!" >> -- Levente "Si vis pacem para bellum!" From tjarvi at qbang.org Fri Aug 22 18:50:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Aug 2008 18:50:32 -0600 (MDT) Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <48AE96AA.6090505@lfarkas.org> References: <48AADD06.7040809@lfarkas.org> <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> <48AE96AA.6090505@lfarkas.org> Message-ID: Hi Farkas, The v2 was simply the second build - no code changes. We are comming out with a new release shortly. I would encourage working with distros as you are. The building of rxtx turns out to be a bottle neck in quick releases. We do want stable releases that work for a year or more but I would have no problems with quicker cycles on developing work. I would have no problem working with someone that did builds that receive less testing more often but they do have to come out for multiple platforms from this end. Thanks for the links. On Fri, 22 Aug 2008, Farkas Levente wrote: > hi, > the packages already build for fedora-9 and centos-5 and here: > http://www.lfarkas.org/linux/packages/ > what i've to patch, the UTS, the configure script, but it's already > fixed in the cvs (in another way) and the loadlibrary. the reasons for > last one can be found here: > https://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_files_that_use_JNI > after we test it i'd like to add these packages to fedora and epel main > repository (that's why it's be useful a new release after 2 years:-) > imho versions are cheap and why not just release 2.1-8? the real code > changes are minimal and if something critical bug found still can > release 2.1-9:-) > > ps. and would be better to use simple number for version like 2.1-7 > rather then 2.1-7v2. > > Oberhuber, Martin wrote: >> Farkas, >> >> there are indeed efforts to get a new RXTX release out the >> door. Your experience as a package maintainer would likely >> be helpful during these efforts, since I'd think it makes >> sense to keep the patches minimal that you must make to >> have the source compile in your environment. >> >> What are the things that you find problematic, apart from >> the UTS thing that you have mentioned before? >> >> What is the timing that you have in mind for your package? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >>> On Behalf Of Farkas Levente >>> Sent: Tuesday, August 19, 2008 4:48 PM >>> To: rxtx at qbang.org >>> Subject: [Rxtx] UTS_RELEASE not defined in newer kernel >>> >>> hi, >>> newer or not so newer linux kernel do not contain the >>> UTS_RELEASE so the >>> current rxtx is not compile on the latest kernels. even if it's >>> commented out in the cvs configure there are other places. >>> i attcahed a patch which fix it (or at least doesn't cause error at >>> non-debug build). >>> >>> ps. is there any plan to the new 2.1-8 release in the near >>> future? there >>> are many changes (at least the license change in all file and in this >>> case create a diff is very difficult)? the latest release more then 2 >>> years old:-( >>> >>> -- >>> Levente "Si vis pacem para bellum!" >>> > > > From andy at triera.net Sat Aug 23 15:17:44 2008 From: andy at triera.net (Andy Rozman) Date: Sat, 23 Aug 2008 21:17:44 +0000 Subject: [Rxtx] port not identified on FreeBSD In-Reply-To: References: Message-ID: <48B07E78.2030306@triera.net> Hi ! I have one small problem... I have started using FreeBSD in last few days and I have come accross a problem with rxtx on FreeBSD. I am using usb-to-serial converter, which is identified under FreeBSD without problem as ucom0, and creates link under /dev called ttyU0, which is correct way to be done under FreeBSD (if device would be unidentified it would be called ugen0 - as usb generic). Problem is that I say to rxtx to get my all serial ports this one is not among them. Which names are permissable under linux-like implementations? Which will be accepted as serial ports? Andy From tjarvi at qbang.org Sat Aug 23 13:57:45 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 23 Aug 2008 13:57:45 -0600 (MDT) Subject: [Rxtx] port not identified on FreeBSD In-Reply-To: <48B07E78.2030306@triera.net> References: <48B07E78.2030306@triera.net> Message-ID: On Sat, 23 Aug 2008, Andy Rozman wrote: > Hi ! > > I have one small problem... I have started using FreeBSD in last few > days and I have come accross a problem with rxtx on FreeBSD. > > I am using usb-to-serial converter, which is identified under FreeBSD > without problem as ucom0, and creates link under /dev called > ttyU0, which is correct way to be done under FreeBSD (if device would be > unidentified it would be called ugen0 - as usb generic). Problem is that > I say to rxtx to get my all serial ports this one is not among them. > Which names are permissable under linux-like implementations? Which will > be accepted as serial ports? > > Andy > Thanks Andy! We will add ttyU* to FreeBSD. For now you can use properties to enable the port. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting#How_does_rxtx_detect_ports.3F__Can_I_override_it.3F The fix: diff -u -r1.16.2.59 RXTXCommDriver.java --- RXTXCommDriver.java 18 Nov 2007 22:32:41 -0000 1.16.2.59 +++ RXTXCommDriver.java 23 Aug 2008 19:55:25 -0000 @@ -644,6 +644,7 @@ { String[] Temp = { "ttyd", //general purpose serial ports + "ttyU", //general purpose USB serial ports "cuaa", //dialout serial ports "ttyA", //Specialix SI/XIO dialin ports "cuaA", //Specialix SI/XIO dialout ports -- Trent Jarvi tjarvi at qbang.org From rick_knight at rlknight.com Mon Aug 4 13:25:10 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Mon, 04 Aug 2008 12:25:10 -0700 Subject: [Rxtx] Sun's Comm API? Message-ID: <48975796.4010600@rlknight.com> I have an application that requires the javax compatible version of RXTX and Sun's comm api. I've been able to download and extract the version of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api anywhere. Can someone tell me where I can find it? Or maybe send me a copy? Also, when I try to build RXTX, configure and make complete successfully but make install failes with this error libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 I've never come accross this error before. How can I get past it? Thanks, Rick From bboyes at systronix.com Mon Aug 4 19:10:01 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:10:01 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48975796.4010600@rlknight.com> References: <48975796.4010600@rlknight.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/cb9c6167/attachment-0026.html From bboyes at systronix.com Mon Aug 4 19:12:37 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:12:37 -0600 Subject: [Rxtx] Towards an RXTX release - CSR BT/USB chipset In-Reply-To: <488FB7E7.8000802@gmail.com> References: <460801A4097E3D4CA04CC64EE648584806C56CF0@ism-mail03.corp.ad.wrs.com> <13557-75390@sneakemail.com> <20980-23424@sneakemail.com> <488FB7E7.8000802@gmail.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/52236088/attachment-0026.html From tjarvi at qbang.org Mon Aug 4 19:42:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 19:42:21 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: On Mon, 4 Aug 2008, Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: > I have an application that requires the javax compatible > version of RXTX > and Sun's comm api. I've been able to download and extract > the version > of RXTX that I need (2.0-7pre2) but I can't find Sun's camm > api > anywhere. Can someone tell me where I can find it? Or maybe > send me a > > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm port > support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have just > a ZIP with only the .class JAR file - no source or docs), has a readme > with these comments: > > This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release.? The 2.0.3 release itself is > no longer distributed.? comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project.? The RxTx project (http://www.rxtx.org ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org) was opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support.? Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins.? Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > ? > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > I hope that is helpful! > It would be nice to work with Sun to resolve those longstanding issues. But it may not be practical unless the process goes as fast and painless as the grandfathering of commapi did. Another option may be the old kaffe extensions that moved to gnu classpathx. These don't have the native libraries but should provide the 2.0 interface and the javax.comm.properties mechansim for SPI. http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Mon Aug 4 20:23:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Mon, 04 Aug 2008 20:23:57 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4897B9BD.5070809@ergotech.com> Has there been any work/would it be possible, to layer a javacomm look-alike on top of the GNU code? The goal is not to move the javax code forward, but to emulate the "legacy" javax packages for people who still need this. Jim Trent Jarvi wrote: > On Mon, 4 Aug 2008, Bruce Boyes wrote: > >> At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible >> version of RXTX >> and Sun's comm api. I've been able to download and extract >> the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm >> api >> anywhere. Can someone tell me where I can find it? Or maybe >> send me a >> >> >> javaxcomm has had a sort of on-again off-again history. The windoze >> version has been languishing for years (literally) but there are newer >> versions for other OS's. >> >> We try to keep links on one of our help pages current: >> http://www.practicalembeddedjava.com/tools/javatools_list.html >> which gets you to here: >> http://java.sun.com/products/javacomm/ >> where it says in fact they no longer even support Windows and Mac: >> "Implementations of the API are currently available for Solaris SPARC, >> Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so >> someone could support it. But I guess that's part of the reason RXTX >> exists! >> >> So one of Sun's own products, SunSPOT, has to use RXTX to get comm port >> support. >> >> The version we use is 2.0 from 11/15/1998. I have posted it on our >> website, which is within the terms of the license agreement contained >> therein (as I understand it). >> >> The last version of javaxcomm for Windows, 2.0.3, (for which I have just >> a ZIP with only the .class JAR file - no source or docs), has a readme >> with these comments: >> >> This distribution contains the comm.jar file original part >> of the COMMAPI 2.0.3 release. The 2.0.3 release itself is >> no longer distributed. comm.jar, which contains the comm >> API java class files (eg. Sun's binary implementation of the >> interface classes), is being made available, unsupported, >> with no obligation to fix bugs, at the request of the RXTX >> project. The RxTx project (http://www.rxtx.org ), uses the >> comm.jar class files, but provides their own native library >> components to provide support for other platforms. >> >> The 2.0.3 comm.jar is being provided in this way because >> as of COMMAPI 3.x, the java binary implementation forked and >> became incompatible with the RxTx project's native code. >> Due to the lack of a clear business case, and to resource >> constraints, no additional resources are being >> provided to provide an alternative engineering solution >> at the time of writing. >> >> RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: >> >> Ultimately the COMMAPI would be better served if a Java >> Community Process JSR (http://www.jcp.org) was opened and >> the COMMAPI was rearchitected to provide a more pluggable >> framework to improve cross-platform support. Such an >> architecture would embody a better defined and better >> documented SPI interface, including a way for comm. ports >> to be revealed to the client application through the API >> via platform-aware plugins. Similarly, native code used >> to access comm port in general could be handled more >> flexibly using a plugin model, whereby on any platform, >> multiple native modules could be in use simultaneously. >> >> Since there are now various ways serial ports can be implemented >> and accessed, modular comm. port JNI native libraries would be >> of benefit insofar as removing the burden of over-generalization >> from any single native component, or inversely, by relieving the >> implicit constraint that comm. drivers be accessed only via a >> monolithic mechanism, such as the UNIX vnode interface. >> >> paul.klissner at sun.com >> 6/10/06 >> >> I hope that is helpful! >> > > It would be nice to work with Sun to resolve those longstanding issues. > But it may not be practical unless the process goes as fast and painless > as the grandfathering of commapi did. > > Another option may be the old kaffe extensions that moved to gnu > classpathx. These don't have the native libraries but should provide > the 2.0 interface and the javax.comm.properties mechansim for SPI. > > http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Mon Aug 4 21:09:15 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 21:09:15 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? Message-ID: Hi Jim, I will not step into the javax.comm namespace without Sun's explicite permission. I fully understand the pain point you are trying to address. In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm Linux) - which remains an integral part of rxtx. At the time it was a win for Sun and rxtx. The Sun commapi license is/was fairly clear that rxtx should not step into that namespace. It made sense as Sun was active in that space and rxtx may go into another namespace - it was an experiment in working with Sun. This may sound silly looking at something that happened almost 10 years ago. In a community of respect which Sun helped create, there is no question about what to do. I hope eventually Sun will step up and do a right thing too. I agree that this is hurting the API more than helping it. There are also questions about how to replace the API in the long term which includes HID support which isn't going well so far. Others that can't even look at Sun's javax.comm today and can look at Kaffe's contribution to classpathx can easily work around such restrictions. On Mon, 4 Aug 2008, Jim Redman wrote: > Has there been any work/would it be possible, to layer a javacomm > look-alike on top of the GNU code? > > The goal is not to move the javax code forward, but to emulate the > "legacy" javax packages for people who still need this. > > Jim > > Trent Jarvi wrote: >> >> It would be nice to work with Sun to resolve those longstanding issues. >> But it may not be practical unless the process goes as fast and painless >> as the grandfathering of commapi did. >> >> Another option may be the old kaffe extensions that moved to gnu >> classpathx. These don't have the native libraries but should provide >> the 2.0 interface and the javax.comm.properties mechansim for SPI. >> >> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From florianmanschwetus at gmx.de Tue Aug 5 05:04:46 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 13:04:46 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: References: <48971C1F.9020806@gmx.de> Message-ID: <489833CE.1040801@gmx.de> Just look at sendCommand in this method I have to place a Thread.sleep(20) after each byte send to get working. Even the event based receive doesn't work fine but this could be may stupidness. The specifikation document (it is on the last pages of the manual) for the beamer could be found on: http://www.optoma.co.uk/support.aspx Florian Manschwetus Trent Jarvi schrieb: > > Hi Florian > > Sorry for the top post in advance. I worry you may not see my answer > under all your code :) > > I have not received this email before. This is 500k of code which I > don't have time to read. I can spend about 5 min on each hobby email > and still get to work in the morning. I have a couple suggestions for > how to get an answer. > > First, cut out your comments and extra code so you can demonstrate the > question (I might even glance and see what is wrong then). Don't go for > a working final product. Isolate the problem using a simple program and > then ask with that as an example. If I did what you just did, I'd have > to post 3/4 of a million lines of code :) > > Second, join the rxtx mail-list and ask there. This will give you 100x > more eyes. I'll also read and try to follow. > > -- > taj > > > > On Mon, 4 Aug 2008, Florian Manschwetus wrote: > >> It could be that my university account is blocked by filters so >> resending from here. >> >> >> Topic is to control Optoma HD80 beamer using rs232 serial chat. >> This code is able to detect power state and switch the beamer on / off. >> connected is the beamer using a digitus usb 2.0 serial adapter with an >> FT232 USB-Serial adapter the systems architecture is amd64. >> >> Please take a look in the sendCommand routine i have to place theire >> those Thread.sleep to get it working. >> Now the question is this correct or is there a better way to get this >> working correctly? >> >> In the javadoc coming with the install i found this: >> setBaudBase >> >> public boolean setBaudBase(int BaudBase) >> throws UnsupportedCommOperationException, >> java.io.IOException >> >> Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 >> before using. >> >> could this explain the error? >> I attached my java source and the protocol description for the beamer >> (available on vendor website). >> >> thx, >> Florian Manschwetus >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: TestRS232.java Type: text/x-java Size: 9143 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0052.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0053.bin From michael.erskine at ketech.com Tue Aug 5 05:53:49 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Tue, 5 Aug 2008 12:53:49 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489833CE.1040801@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> > Just look at sendCommand in this method I have to place a > Thread.sleep(20) after each byte send to get working. Even the event > based receive doesn't work fine but this could be may stupidness. Hi Florian, Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. Regards, Michael Erskine. From florianmanschwetus at gmx.de Tue Aug 5 07:28:15 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:28:15 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> Message-ID: <4898556F.8000208@gmx.de> Michael Erskine schrieb: >> Just look at sendCommand in this method I have to place a >> Thread.sleep(20) after each byte send to get working. Even the event >> based receive doesn't work fine but this could be may stupidness. > > Hi Florian, > > Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. > > Regards, > Michael Erskine. > Ok, sounds fine for the receiving problem. But why i have to wait after each byte when sending a command squence? (the for loop in send command) Florian > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/284f350c/attachment-0025.bin From florianmanschwetus at gmx.de Tue Aug 5 07:44:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:44:14 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <4898592E.2020908@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >>> Just look at sendCommand in this method I have to place a >>> Thread.sleep(20) after each byte send to get working. Even the event >>> based receive doesn't work fine but this could be may stupidness. >> >> Hi Florian, >> >> Yes, naturally you'll have to wait for a response from the other end. >> Why not wait for notification from the event thread perhaps using a >> BlockingDeque rather than your LinkedList. Generally I >> try to decouple all input and output streams: in your case your >> application is operating synchronously like the "expect" program >> (http://expect.nist.gov/) so waits (or timeouts) will need to be >> factored in. >> >> Regards, >> Michael Erskine. >> > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) > > Florian Furthermore there is this basic baud with this confusing javadoc entry: public boolean setBaudBase(int BaudBase) throws UnsupportedCommOperationException, java.io.IOException Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 before using. maybe this could explain something Florian >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/006c7425/attachment-0025.bin From jredman at ergotech.com Tue Aug 5 09:13:36 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 05 Aug 2008 09:13:36 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: Message-ID: <48986E20.3060104@ergotech.com> Trent, So two issues: 1) Technically I'm still not sure how easy/practical a layer would be. The problems are always classes like listeners, and wrapping returns of gnu.io classes. I really see it as a "delegate" type of concept. Any thoughts or ideas of the practicality of this approach? The idea is not to modify RXTX. 2) Javax. The javax namespace does seem to be in widespread use outside of Sun (the same is true for the java namespace). The classpath extensions, or some other location, should be interested in a JavaComm implementation even if it does have dependencies on RXTX. Would you have any philosophical objection to an approach like that? Of course, I suspect it might be better if someone with that authority at Sun would admit that the javax namespace is already in the wild and that there is no problem with it being used within RXTX. Jim Trent Jarvi wrote: > Hi Jim, > > I will not step into the javax.comm namespace without Sun's explicite > permission. I fully understand the pain point you are trying to address. > > In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm > Linux) - which remains an integral part of rxtx. At the time it was a win for > Sun and rxtx. > > The Sun commapi license is/was fairly clear that rxtx should not step into that > namespace. It made sense as Sun was active in that space and rxtx may go into > another namespace - it was an experiment in working with Sun. > > This may sound silly looking at something that happened almost 10 years ago. > In a community of respect which Sun helped create, there is no question about > what to do. I hope eventually Sun will step up and do a right thing too. > > I agree that this is hurting the API more than helping it. There are also > questions about how to replace the API in the long term which includes HID > support which isn't going well so far. > > Others that can't even look at Sun's javax.comm today and can look at Kaffe's > contribution to classpathx can easily work around such restrictions. > > On Mon, 4 Aug 2008, Jim Redman wrote: > >> Has there been any work/would it be possible, to layer a javacomm >> look-alike on top of the GNU code? >> >> The goal is not to move the javax code forward, but to emulate the >> "legacy" javax packages for people who still need this. >> >> Jim >> >> Trent Jarvi wrote: >>> It would be nice to work with Sun to resolve those longstanding issues. >>> But it may not be practical unless the process goes as fast and painless >>> as the grandfathering of commapi did. >>> >>> Another option may be the old kaffe extensions that moved to gnu >>> classpathx. These don't have the native libraries but should provide >>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>> >>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From sandeep at genevasoftech.com Tue Aug 5 11:18:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Tue, 05 Aug 2008 22:48:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <48988B6C.5080409@genevasoftech.com> Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. *-- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/ad20f1cb/attachment-0025.html From Martin.Oberhuber at windriver.com Tue Aug 5 13:30:17 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Tue, 5 Aug 2008 21:30:17 +0200 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Sandeep, shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on Sol7 but I've successfully run it on Sol9 and Sol10. Or is your request really about a native 64bit variant? I'm afraid that then you're out of luck since I think that quite a bit of RXTX is not yet ready for 64 bit. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Sandeep Kumar K Sent: Tuesday, August 05, 2008 7:19 PM To: rxtx at qbang.org Subject: [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so for Solaris 9 Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. -- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/81b7f988/attachment-0025.html From tjarvi at qbang.org Tue Aug 5 22:38:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 22:38:34 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 5 Aug 2008, Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built > on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid that > then > you're out of luck since I think that quite a bit of RXTX is not yet > ready > for 64 bit. > While rxtx-2.1-7 probably has problems, The CVS code should be OK for 64 bit Solaris. If it isn't, let me know and I'll find which patch is missing. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Aug 5 23:13:00 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 23:13:00 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48986E20.3060104@ergotech.com> References: <48986E20.3060104@ergotech.com> Message-ID: On Tue, 5 Aug 2008, Jim Redman wrote: > Trent, > > So two issues: > > 1) Technically I'm still not sure how easy/practical a layer would be. The > problems are always classes like listeners, and wrapping returns of gnu.io > classes. I really see it as a "delegate" type of concept. Any thoughts or > ideas of the practicality of this approach? The idea is not to modify RXTX. I have not put too much thought into this. I assume you want what rxtx 2.0 provided to tie into javax.comm implementations. More classes could be added to rxtx 2.1-7 for SPI support. Maintaining rxtx-2.0 could also be handed to someone if they like. > > 2) Javax. The javax namespace does seem to be in widespread use outside of > Sun (the same is true for the java namespace). The classpath extensions, or > some other location, should be interested in a JavaComm implementation even > if it does have dependencies on RXTX. Would you have any philosophical > objection to an approach like that? > No problems. Classpathx would be a possible place to do it. I'd suggest thinking twice about what this involves in practical terms. You would be wanting to revive the 2.0 API while Sun is at 3.0 and grandfathering the JSR. This undermines the main reason (established api) for using the javax.comm namespace and does not leave such a project in a good position. The only win I see here is maintaining support for applications that can't migrate namespaces. Not that that isn't important. At some point it is going to be less work to just edit the bytecode :) Such a javax.comm effort would also be signing up new projects that decided to use the work up for concerns they probably will not understand or expect. That probably isn't a good path to facilitate for new projects at this time. We will put a good faith effort to work well with others but keep in mind the project has limited bandwidth for such efforts. > Of course, I suspect it might be better if someone with that authority at Sun > would admit that the javax namespace is already in the wild and that there is > no problem with it being used within RXTX. > > Jim > > Trent Jarvi wrote: >> Hi Jim, >> >> I will not step into the javax.comm namespace without Sun's explicite >> permission. I fully understand the pain point you are trying to address. >> >> In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java >> Comm Linux) - which remains an integral part of rxtx. At the time it was a >> win for Sun and rxtx. >> >> The Sun commapi license is/was fairly clear that rxtx should not step into >> that namespace. It made sense as Sun was active in that space and rxtx may >> go into another namespace - it was an experiment in working with Sun. >> >> This may sound silly looking at something that happened almost 10 years >> ago. In a community of respect which Sun helped create, there is no >> question about what to do. I hope eventually Sun will step up and do a >> right thing too. >> >> I agree that this is hurting the API more than helping it. There are also >> questions about how to replace the API in the long term which includes HID >> support which isn't going well so far. >> >> Others that can't even look at Sun's javax.comm today and can look at >> Kaffe's contribution to classpathx can easily work around such >> restrictions. >> >> On Mon, 4 Aug 2008, Jim Redman wrote: >> >>> Has there been any work/would it be possible, to layer a javacomm >>> look-alike on top of the GNU code? >>> >>> The goal is not to move the javax code forward, but to emulate the >>> "legacy" javax packages for people who still need this. >>> >>> Jim >>> >>> Trent Jarvi wrote: >>>> It would be nice to work with Sun to resolve those longstanding issues. >>>> But it may not be practical unless the process goes as fast and painless >>>> as the grandfathering of commapi did. >>>> >>>> Another option may be the old kaffe extensions that moved to gnu >>>> classpathx. These don't have the native libraries but should provide >>>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>>> >>>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From sandeep at genevasoftech.com Wed Aug 6 00:03:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Wed, 06 Aug 2008 11:33:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: <48993EB8.30107@genevasoftech.com> Thank you Mr. Martin for your suggestion. The native file which is given in rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am getting the following error . Any suggestions to solve this issue. I am using Solaris SPARC 64 bit machine. ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) thrown while loading gnu.io.RXTXCommDriver Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(Unknown Source) at java.lang.ClassLoader.loadLibrary(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) at com.ReadFromModem.main(ReadFromModem.java:84) * * *Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid > that then > you're out of luck since I think that quite a bit of RXTX is not yet ready > for 64 bit. > > Cheers, > -- > *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > ------------------------------------------------------------------------ > *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On > Behalf Of *Sandeep Kumar K > *Sent:* Tuesday, August 05, 2008 7:19 PM > *To:* rxtx at qbang.org > *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so > for Solaris 9 > > Hi, > > Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 > bit machine. The librxtxSerial.so given in website is for Solaris 8. > > *-- > > Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/1e920343/attachment-0025.html From tjarvi at qbang.org Wed Aug 6 00:21:42 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 00:21:42 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <48993EB8.30107@genevasoftech.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> <48993EB8.30107@genevasoftech.com> Message-ID: Hi Sandeep You may be out of luck unless you can compile the 2.1 src in CVS (requires gnu make and gcc). But you could try the ToyBox(R)(TM) which is a collection of WiLdLy untested cross compiled 2.1-7 binaries covering everything from the ibm z series to embeded arm/ppc. To give an idea how poorly these are tested, I don't even know if z series machines have a serial port. ftp://www.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Solaris They should at least match the binary types. Actually, I think if you use the rxtx jar from CVS with that file, it should 'work' as the fix for 64 bits was in java not the native code. You could just cd rxtx*/src; javac *.java then jar -cf RXTXcomm.jar `find -name \*.class` to create the hybrid which will complain about version information a bit. On Wed, 6 Aug 2008, Sandeep Kumar K wrote: > Thank you Mr. Martin for your suggestion. The native file which is given in > rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am > getting the following error . > Any suggestions to solve this issue. > I am using Solaris SPARC 64 bit machine. > > ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar > java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 > (Possible cause: architecture word > width mismatch) thrown while loading gnu.io.RXTXCommDriver > Exception in thread "main" java.lang.UnsatisfiedLinkError: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF > class: ELFCLASS64 (Possible cause: > architecture word width mismatch) > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(Unknown Source) > at java.lang.ClassLoader.loadLibrary(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > at com.ReadFromModem.main(ReadFromModem.java:84) > > * > * > > *Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > > > Oberhuber, Martin wrote: >> Sandeep, >> shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse >> variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on >> Sol7 but I've successfully run it on Sol9 and Sol10. >> Or is your request really about a native 64bit variant? I'm afraid that >> then >> you're out of luck since I think that quite a bit of RXTX is not yet ready >> for 64 bit. >> Cheers, >> -- >> *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> ------------------------------------------------------------------------ >> *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On >> Behalf Of *Sandeep Kumar K >> *Sent:* Tuesday, August 05, 2008 7:19 PM >> *To:* rxtx at qbang.org >> *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so >> for Solaris 9 >> >> Hi, >> >> Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 >> bit machine. The librxtxSerial.so given in website is for Solaris 8. >> >> *-- >> Thanks & Regards >> >> Sandeep Kumar K >> Sr. Software Engineer >> Geneva Software Technologies >> Whitefield, Bangalore >> Mob : 9880193454* >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> From michael.erskine at ketech.com Wed Aug 6 01:39:28 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 6 Aug 2008 08:39:28 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Florian Manschwetus wrote: > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) Hi Florian, I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. Regards, Michael Erskine. From florianmanschwetus at gmx.de Wed Aug 6 02:53:16 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 06 Aug 2008 10:53:16 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Message-ID: <4899667C.6010706@gmx.de> Michael Erskine schrieb: > Florian Manschwetus wrote: >> Ok, sounds fine for the receiving problem. >> But why i have to wait after each byte when sending a command squence? >> (the for loop in send command) > > Hi Florian, > I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. > > Regards, > Michael Erskine. > correct with a terminal on the other end it works, my idea was that this basic baud has some influence. Could some one explain what it is for? Florian > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/c2b4fa84/attachment-0025.bin From rick_knight at rlknight.com Wed Aug 6 13:01:07 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:01:07 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F4F3.3020707@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > I have an application (Readerware) that uses RXTX with Javax to access the serial port. This used to work fine under previous Linux' and Java, but something has changed, I assume with Java itself , that is causing the application to fail with a link error. The application is not able to find librxtxSerialParallel.so. RXTX supplies librxtxSerial.so and librxtxParallel.so, but not librxtxSerialParallel.so. Where can I get librxtxSerialParallel.so, or do I need it? Is something else causing the lib to not be found? Thanks, Rick Knight From rick_knight at rlknight.com Wed Aug 6 13:17:55 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:17:55 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F8E3.5060400@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Thanks for the reply. The developer of the app I'm trying to use (Readerware) has sent me a copy of the comm.api and I've copied the library (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar into the proper places. When I try to run the application, I get this error... Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: /usr/lib/libSolarisSerialParallel.so: /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not little-endian (Possible cause: endianness mismatch) Caught java.lang.UnsatisfiedLinkError: com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I while loading driver com.sun.comm.SolarisDriver Is there a way around this error? Thanks again, Rick Knight From jlar310 at gmail.com Wed Aug 6 13:37:42 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 14:37:42 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899F8E3.5060400@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > The developer of the app I'm trying to use (Readerware) has sent me a > copy of the comm.api and I've copied the library > (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar > into the proper places. When I try to run the application, I get this > error... > > Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: > /usr/lib/libSolarisSerialParallel.so: > /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not > little-endian (Possible cause: endianness mismatch) > Caught java.lang.UnsatisfiedLinkError: > com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I > > while loading driver com.sun.comm.SolarisDriver > > Is there a way around this error? What host OS are you running? From your original post it looks like 32 bit Linux. The libSolarisSerialParallel.so file is for Sun Solaris and will vary depending on the underlying hardware architecture as well. Sorry for the double post Rick, but I failed to send this to the list the first time... -- Jeff From rick_knight at rlknight.com Wed Aug 6 13:44:29 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:44:29 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: <4899FF1D.9030504@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > > >> The developer of the app I'm trying to use (Readerware) has sent me a >> copy of the comm.api and I've copied the library >> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >> into the proper places. When I try to run the application, I get this >> error... >> >> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >> /usr/lib/libSolarisSerialParallel.so: >> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >> little-endian (Possible cause: endianness mismatch) >> Caught java.lang.UnsatisfiedLinkError: >> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >> >> while loading driver com.sun.comm.SolarisDriver >> >> Is there a way around this error? >> > > What host OS are you running? From your original post it looks like 32 > bit Linux. > > The libSolarisSerialParallel.so file is for Sun Solaris and will vary > depending on the underlying hardware architecture as well. > > I'm running Kubuntu Linux (debian based). It's 32 bit. Rick Knight From jlar310 at gmail.com Wed Aug 6 15:33:23 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 16:33:23 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > I don't think Sun did binary libraries for Linux in the 2.0 version. Can someone with more historical experience than I confirm that? I recently tried to port a Comm API application from Solaris sparc to Linux x86 and likewise could not get my hands on the binary libraries. I eventually just re-wrote the code to use the gnu namespace packages and rxtx 2.1. What I don't understand is why your application vendor does not provide everything you need to run their software. FYI: I have librxtxParallel.so and librxtxSerial.so installed at JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is /usr/java/default which is actually a softlink to /usr/java/jre1.6.0_05. -- Jeff From defiantlew at yahoo.com.au Wed Aug 6 16:29:33 2008 From: defiantlew at yahoo.com.au (Lew L) Date: Thu, 7 Aug 2008 08:29:33 +1000 Subject: [Rxtx] Sun's Comm API Documentation References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> Message-ID: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> As a matter of interest is the Sun Comm API documentation available somewhere? I have tried the Sun site but it seems to have been removed. Unless I have missed the documentation for RXTX? I javadocced the RXTX source but information (to me) is minimal. Somewhere I got the impression that the Sun Comm API docs is, or was, compatible with RXTX, what is the best docs to use in conjuntion with RXTX and where may the be available? Cheers Lew From rick_knight at rlknight.com Wed Aug 6 17:18:33 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:18:33 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A3149.4050306@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff I'm not sure if I posted this here or not, but when I try to build RXTX from source I get this install error... make all-am make[1]: Entering directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' make[1]: Nothing to be done for `all-am'. make[1]: Leaving directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 Can you tell me how to get past this error and get RXTX built and installed? Thanks, Rick From bboyes at systronix.com Wed Aug 6 17:40:12 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Wed, 06 Aug 2008 17:40:12 -0600 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: At 16:29 08/06/2008, Lew L wrote: >As a matter of interest is the Sun Comm API documentation available >somewhere? I have tried the Sun site but it seems to have been removed. It's in the file we have posted, link in prev email (sorry, in a huge hurry right now). Javadocs definitely there. >Unless I have missed the documentation for RXTX? I javadocced the RXTX >source but information (to me) is minimal. >Somewhere I got the impression that the Sun Comm API docs is, or was, >compatible with RXTX, what is the best docs to use in conjuntion with RXTX >and where may the be available? Yeah, this is one of my concerns/beefs. There is little documentation for RXTX and it isn't just the same as javaxcomm. I would be willing to help out writing docs for RXTX! Yes really... esp if we can fix the Bluetooth issues. best regards Bruce >Cheers >Lew > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx ------- WWW.SYSTRONIX.COM ---------- Real embedded Java and much more +1-801-534-1017 Salt Lake City, USA From rick_knight at rlknight.com Wed Aug 6 17:54:08 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:54:08 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A39A0.2090309@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff, I would like for my vendor to switch to rxtx 2.1. It would make things much easier for me. I'm not sure why he's still using the javax compatible code. He's a small operation. Re-writing the code to use gnu namespace sounds like a major overhaul. Was it? Thanks, Rick From tjarvi at qbang.org Wed Aug 6 21:35:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:35:12 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: >> >>> Jeff wrote: >>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>>> >>>> >>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things > much easier for me. I'm not sure why he's still using the javax > compatible code. He's a small operation. Re-writing the code to use gnu > namespace sounds like a major overhaul. Was it? > Hi Jeff, The changes are fairly mechanical. Imports need to change and any explicite use of the namespace needs to change such as catching an exception. The following script was made for maintaining rxtx 2.0 but can apply to other needs. It is in the contrib dir with rxtx source. #!/bin/sh # Don't use! :) # # Sat, 03 May 2003 16:45:08 Modifications from J?rg Weule # Create a ed-cmd for the change of one pattern # case $1 in gnu) X=g/javax_comm/s+javax_comm+gnu_io+g ;; javax) X=g/gnu_io/s+gnu_io+javax_comm+g ;; *) echo;echo;echo From the top rxtx directory run;echo;echo -e \\t./ChangePackage.sh gnu;echo -e \\t\\tor;echo -e \\t./ChangePackage.sh javax;echo;echo; exit 0 ;; esac # # ed will be used to keep the owner and mode of the files unchanged. # We have run the ed-script for the characters '.' '/' as well. # "tr _ $D" do the change. # find . -type f -a -print | grep -v $0 | (while read F ; do ( echo $X; echo $X| tr _ /; echo $X| tr _ .; echo w; echo q ) | ed $F 2>&1 >/dev/null done ) # # Now we do little changes at the Makefiles. Hope that all we need. # find . -name Makefile\* -a -print | (while read F ; do cat < References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: On Thu, 7 Aug 2008, Lew L wrote: > As a matter of interest is the Sun Comm API documentation available > somewhere? I have tried the Sun site but it seems to have been removed. > > Unless I have missed the documentation for RXTX? I javadocced the RXTX > source but information (to me) is minimal. > Somewhere I got the impression that the Sun Comm API docs is, or was, > compatible with RXTX, what is the best docs to use in conjuntion with RXTX > and where may the be available? > Hi Lew, The documentation on Sun's website is accurate. The changes that are problematic in 3.0 are on the backside which rxtx used to plug into. http://java.sun.com/products/javacomm/reference/api/index.html CommPortIdentifier may have some minor differences (judging by the authors notes). -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Aug 6 21:46:08 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:46:08 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > If javax.comm.properties is properly installed and you are using a 2.0 version of Sun's commapi with rxtx 2.0, you should not see the library attempt to load libSolarisSerialParallel.so. Sun CommAPI 3.0 will not work with any version of rxtx as it is hard coded to use the shared library. See the INSTALL file with rxtx-2.0 source for more help with the properties file. -- Trent Jarvi tjarvi at qbang.org From jlar310 at gmail.com Thu Aug 7 06:32:06 2008 From: jlar310 at gmail.com (Jeff) Date: Thu, 7 Aug 2008 07:32:06 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > Jeff wrote: >> >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >> wrote: >> >>> >>> Jeff wrote: >>> >>>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>> wrote: >>>> >>>> >>>> >>>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things much > easier for me. I'm not sure why he's still using the javax compatible code. > He's a small operation. Re-writing the code to use gnu namespace sounds like > a major overhaul. Was it? I found it quite easy. In fact, in order to accommodate the transition, I actually separated all of the code that deals directly with the Comm API or RXTX into a helper class. The helper class was then coded to use reflection to determine which library was available and then instantiate the necessary objects. No direct imports of either library are used. The main application just needs to get it's hands on the IO streams and need not deal directly with the libraries. Other programs may not be so simple... But this doesn't really help you unless your vendor forks over the source code... -- Jeff From rick_knight at rlknight.com Thu Aug 7 09:47:12 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Thu, 07 Aug 2008 08:47:12 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: <489B1900.10108@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >>> wrote: >>> >>> >>>> Jeff wrote: >>>> >>>> >>>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>>> copy of the comm.api and I've copied the library >>>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>>> into the proper places. When I try to run the application, I get this >>>>>> error... >>>>>> >>>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>>> /usr/lib/libSolarisSerialParallel.so: >>>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>>> little-endian (Possible cause: endianness mismatch) >>>>>> Caught java.lang.UnsatisfiedLinkError: >>>>>> >>>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>>> >>>>>> while loading driver com.sun.comm.SolarisDriver >>>>>> >>>>>> Is there a way around this error? >>>>>> >>>>>> >>>>>> >>>>> What host OS are you running? From your original post it looks like 32 >>>>> bit Linux. >>>>> >>>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>>> depending on the underlying hardware architecture as well. >>>>> >>>>> >>>>> >>>>> >>>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>>> >>>> >>>> >>> I don't think Sun did binary libraries for Linux in the 2.0 version. >>> Can someone with more historical experience than I confirm that? >>> >>> I recently tried to port a Comm API application from Solaris sparc to >>> Linux x86 and likewise could not get my hands on the binary libraries. >>> I eventually just re-wrote the code to use the gnu namespace packages >>> and rxtx 2.1. >>> >>> What I don't understand is why your application vendor does not >>> provide everything you need to run their software. >>> >>> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >>> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >>> /usr/java/default which is actually a softlink to >>> /usr/java/jre1.6.0_05. >>> >>> >>> >> Jeff, >> >> I would like for my vendor to switch to rxtx 2.1. It would make things much >> easier for me. I'm not sure why he's still using the javax compatible code. >> He's a small operation. Re-writing the code to use gnu namespace sounds like >> a major overhaul. Was it? >> > > I found it quite easy. In fact, in order to accommodate the > transition, I actually separated all of the code that deals directly > with the Comm API or RXTX into a helper class. The helper class was > then coded to use reflection to determine which library was available > and then instantiate the necessary objects. No direct imports of > either library are used. The main application just needs to get it's > hands on the IO streams and need not deal directly with the libraries. > Other programs may not be so simple... > > But this doesn't really help you unless your vendor forks over the > source code... > > Jeff, This may not help me directly, but I'm going to forward this thread to the vendor. I think he'll be open to making things work. Thanks again, Rick Knight From agusmunioz at gmail.com Thu Aug 7 16:39:51 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Thu, 7 Aug 2008 19:39:51 -0300 Subject: [Rxtx] How to send ack? Message-ID: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Hi, I'm still learning about serial communication and I have some doubts. I've got this question about how to do the following thing in rxtx. I have this hardware that connect to a PC using a serial port. These hardware receives data from a telephone line, proccess it, and then send it forward to the serial port. I've used a program named wincomm that shows what information is send it through the serial port and I have the nex behaviour: The hardware has a buffer where all data is stored, that cannot be sent it through the seria port. The program reads the first data send it by the hardware, and keep reading the same data always. There is a button in the application that says enable Ack, and when I click, then the hardware start to send all the stored information, and all the information is shown. I write a class, using rxtx that reads the serial port, and the same thing happens, it remains reading the same (first) data all the time. And I thing something like the enable Ack I'm missing. How can I do this enable Ack from my java code using rxtx? Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080807/e0a0f9a1/attachment-0023.html From ajmas at sympatico.ca Thu Aug 7 18:26:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 7 Aug 2008 20:26:41 -0400 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: <4BF42297-81E2-4BB8-A89F-1D43588379AE@sympatico.ca> On 6-Aug-08, at 19:40 , Bruce Boyes wrote: >> Unless I have missed the documentation for RXTX? I javadocced the >> RXTX >> source but information (to me) is minimal. >> Somewhere I got the impression that the Sun Comm API docs is, or was, >> compatible with RXTX, what is the best docs to use in conjuntion >> with RXTX >> and where may the be available? > > Yeah, this is one of my concerns/beefs. There is little documentation > for RXTX and it isn't just the same as javaxcomm. > > I would be willing to help out writing docs for RXTX! Yes really... > esp if we can fix the Bluetooth issues. If you want to contribute documentation then the best place to do that is the wiki. If there is anything missing or that could be improved on then please do so. If there are any points that you would like to see improved, for which you don't have the knowledge then ask on the mailing list for a volunteer. Andre From florianmanschwetus at gmx.de Fri Aug 8 03:04:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Fri, 08 Aug 2008 11:04:14 +0200 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Message-ID: <489C0C0E.2020401@gmx.de> Agustin Mu?oz schrieb: > Hi, I'm still learning about serial communication and I have some > doubts. I've got this question about how to do the following thing in rxtx. > I have this hardware that connect to a PC using a serial port. These > hardware receives data from a telephone line, proccess it, and then send > it forward to the serial port. I've used a program named wincomm that > shows what information is send it through the serial port and I have the > nex behaviour: > > The hardware has a buffer where all data is stored, that cannot be sent > it through the seria port. > The program reads the first data send it by the hardware, and keep > reading the same data always. > There is a button in the application that says enable Ack, and when I > click, then the hardware start to send all the stored information, and > all the information is shown. > > I write a class, using rxtx that reads the serial port, and the same > thing happens, it remains reading the same (first) data all the time. > And I thing something like the enable Ack I'm missing. > How can I do this enable Ack from my java code using rxtx? Afaik, a look at man ascii reveals: Okt Dez Hex Char 006 6 06 ACK So, i hope this will do the job: send(6); florian > > Thanks in advance > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/5b4965f8/attachment-0023.bin From agusmunioz at gmail.com Fri Aug 8 16:31:00 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 19:31:00 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <489C0C0E.2020401@gmx.de> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> Message-ID: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Hi Florian, thanks for the answer. By send(6) you mean to get the port OutputStream and write a 6? I try that but it didn't work. Any suggestion? Thanks On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < florianmanschwetus at gmx.de> wrote: > Agustin Mu?oz schrieb: > > Hi, I'm still learning about serial communication and I have some doubts. >> I've got this question about how to do the following thing in rxtx. >> I have this hardware that connect to a PC using a serial port. These >> hardware receives data from a telephone line, proccess it, and then send it >> forward to the serial port. I've used a program named wincomm that shows >> what information is send it through the serial port and I have the nex >> behaviour: >> >> The hardware has a buffer where all data is stored, that cannot be sent >> it through the seria port. >> The program reads the first data send it by the hardware, and keep reading >> the same data always. >> There is a button in the application that says enable Ack, and when I >> click, then the hardware start to send all the stored information, and all >> the information is shown. >> >> I write a class, using rxtx that reads the serial port, and the same thing >> happens, it remains reading the same (first) data all the time. And I thing >> something like the enable Ack I'm missing. >> How can I do this enable Ack from my java code using rxtx? >> > Afaik, a look at man ascii reveals: > Okt Dez Hex Char > 006 6 06 ACK > So, i hope this will do the job: > send(6); > > florian > >> >> Thanks in advance >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/7f3fba42/attachment-0022.html From agusmunioz at gmail.com Fri Aug 8 18:39:27 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 21:39:27 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Message-ID: <988288430808081739x7f9e7889id82591d5a9e2b4f6@mail.gmail.com> Ok, Florian, it works!! my problem was that I've been sending, through the OutputStream, the bytes of 6 as a string: out.write("6".getBytes()); but then I realized that you can write an int on an OuptuStream, so I tried that and It works: out.write(6); Thank you for the guidance!! On Fri, Aug 8, 2008 at 7:31 PM, Agustin Mu?oz wrote: > Hi Florian, thanks for the answer. By send(6) you mean to get the port > OutputStream and write a 6? > > I try that but it didn't work. > > Any suggestion? > > Thanks > > > On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < > florianmanschwetus at gmx.de> wrote: > >> Agustin Mu?oz schrieb: >> >> Hi, I'm still learning about serial communication and I have some doubts. >>> I've got this question about how to do the following thing in rxtx. >>> I have this hardware that connect to a PC using a serial port. These >>> hardware receives data from a telephone line, proccess it, and then send it >>> forward to the serial port. I've used a program named wincomm that shows >>> what information is send it through the serial port and I have the nex >>> behaviour: >>> >>> The hardware has a buffer where all data is stored, that cannot be sent >>> it through the seria port. >>> The program reads the first data send it by the hardware, and keep >>> reading the same data always. >>> There is a button in the application that says enable Ack, and when I >>> click, then the hardware start to send all the stored information, and all >>> the information is shown. >>> >>> I write a class, using rxtx that reads the serial port, and the same >>> thing happens, it remains reading the same (first) data all the time. And I >>> thing something like the enable Ack I'm missing. >>> How can I do this enable Ack from my java code using rxtx? >>> >> Afaik, a look at man ascii reveals: >> Okt Dez Hex Char >> 006 6 06 ACK >> So, i hope this will do the job: >> send(6); >> >> florian >> >>> >>> Thanks in advance >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/b918ab3d/attachment-0022.html From florianmanschwetus at gmx.de Sat Aug 9 00:45:43 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Sat, 09 Aug 2008 08:45:43 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4899667C.6010706@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> Message-ID: <489D3D17.9090209@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >> Florian Manschwetus wrote: >>> Ok, sounds fine for the receiving problem. >>> But why i have to wait after each byte when sending a command squence? >>> (the for loop in send command) >> >> Hi Florian, >> I'd imagine you probably don't! You could send all bytes in one go and >> RXTX would send them. The problem is most probably the other end: >> perhaps it has a really small buffer, some non-standard UART, or a >> crazy timing issue. If you attach a terminal to your output and send >> all the bytes of a command in one go they should appear no problem. >> >> Regards, >> Michael Erskine. >> > correct with a terminal on the other end it works, my idea was that this > basic baud has some influence. Could some one explain what it is for? > > Florian To make it more clear, my problem is that i can't use: outputStream.write(byte[]); => Beamer doesn't understand the sequence. (mostly no answer when he answers then *001) when i use this construct instead: for (int i = 0; i < command.length; i++) { this.outputStream.write(command[i]); try { Thread.sleep(25); } catch (InterruptedException e) { // TODO Auto-generated catch block e.printStackTrace(); } } it works nearly reliable. So what could it be? This Basic Baud is what exactly? Florian -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080809/692304ee/attachment-0022.bin From tjarvi at qbang.org Sat Aug 9 16:37:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Aug 2008 16:37:19 -0600 (MDT) Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489D3D17.9090209@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> <489D3D17.9090209@gmx.de> Message-ID: On Sat, 9 Aug 2008, Florian Manschwetus wrote: > Florian Manschwetus schrieb: >> Michael Erskine schrieb: >>> Florian Manschwetus wrote: >>>> Ok, sounds fine for the receiving problem. >>>> But why i have to wait after each byte when sending a command squence? >>>> (the for loop in send command) >>> >>> Hi Florian, >>> I'd imagine you probably don't! You could send all bytes in one go and >>> RXTX would send them. The problem is most probably the other end: perhaps >>> it has a really small buffer, some non-standard UART, or a crazy timing >>> issue. If you attach a terminal to your output and send all the bytes of a >>> command in one go they should appear no problem. >>> >>> Regards, >>> Michael Erskine. >>> >> correct with a terminal on the other end it works, my idea was that this >> basic baud has some influence. Could some one explain what it is for? >> >> Florian > To make it more clear, > my problem is that i can't use: > outputStream.write(byte[]); > => Beamer doesn't understand the sequence. (mostly no answer when he answers > then *001) > > when i use this construct instead: > > for (int i = 0; i < command.length; i++) { > this.outputStream.write(command[i]); > try { > Thread.sleep(25); > } catch (InterruptedException e) { > // TODO Auto-generated catch block > e.printStackTrace(); > } > } > > it works nearly reliable. > > So what could it be? This Basic Baud is what exactly? > I suspect you are using the 'moon protocol' and don't know it. RXTX enables this by default. The buffer on the other end is first in first out while reading. If the buffer is full, the bits are hand carried to the moon and burried. Then if the other side reads a couple bytes, two more bytes go into the buffer followed by more moon protocol. The resulting array of bytes the other side reads may appear to be scrambled until you go to the moon, get the bits and insert them in the right place. Flow control can prevent the default moon protocol and throttles the communiation by almost writing a byte at a time as need be. Hardware flow control is preferable but software flow control should also work. Read and write can appear to hang if the other side is not connected. This is why we don't enable them all the time. If you can't use flow control, you have to take care with the moon protocol and give the other side time to read. That is what your slower version of write is doing. -- Trent Jarvi tjarvi at qbang.org From rxtx at allenjb.me.uk Mon Aug 11 08:06:36 2008 From: rxtx at allenjb.me.uk (AllenJB) Date: Mon, 11 Aug 2008 15:06:36 +0100 Subject: [Rxtx] Disabling EV_RXFLAG Message-ID: <48A0476C.2090800@allenjb.me.uk> Hi all, I'm working with a device which does not use an EvtChar and need to disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an event mask of FD 01 00 00. The reference software I have uses FB 00 00 00. With the rxtx mask I get framing errors which I believe are caused when the EvtChar is received. Is there currently a way with rxtx (I've using rxtx from Java) to disable EV_RXFLAG? If not from Java, where would I start if I wanted to turn the EV_RXFLAG option off in the C code? I've had a grep of the rxtx source code, but I can't see where EV_RXFLAG is being set. Thanks in advance, AllenJB From tjarvi at qbang.org Mon Aug 11 14:17:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Aug 2008 14:17:27 -0600 (MDT) Subject: [Rxtx] Disabling EV_RXFLAG In-Reply-To: <48A0476C.2090800@allenjb.me.uk> References: <48A0476C.2090800@allenjb.me.uk> Message-ID: On Mon, 11 Aug 2008, AllenJB wrote: > Hi all, > > I'm working with a device which does not use an EvtChar and need to > disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an > event mask of FD 01 00 00. The reference software I have uses FB 00 00 > 00. With the rxtx mask I get framing errors which I believe are caused > when the EvtChar is received. > > Is there currently a way with rxtx (I've using rxtx from Java) to > disable EV_RXFLAG? > > If not from Java, where would I start if I wanted to turn the EV_RXFLAG > option off in the C code? I've had a grep of the rxtx source code, but I > can't see where EV_RXFLAG is being set. > > Thanks in advance, > > AllenJB Hi Allen, I'd look at termios.c::tcsetattr() and termios.c::FillDCB() -- Trent Jarvi tjarvi at qbang.org From superdadusa at gmail.com Tue Aug 12 13:57:32 2008 From: superdadusa at gmail.com (John Choi) Date: Tue, 12 Aug 2008 13:57:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. Message-ID: Hi all, Just let you all know I just start to learn Java. I have download the serial comm package and the source code from open source communities.. I was able to verify with the given message string via serial monitor. when the given message string sends to the serial port then the character return added to the end of string by default if I use "Hello World" however if I changed to something else other than "Hello, World" there is no character return add to the end of string. I thing the library download from rxtx.org has implemented for the special strings. I can do like "login\n" in the string message to make character return but I don't want to add this individual custom character for each command return in every static message string I send, Can any who have done this might help me? Basically, something like this,, Write and add function to the program write a command, Reads the respond from a serial device.. Function handles multiple messages, Write: "com open" Read: Welcome to my world" expected Write: "admin" Read: Password?, expected Write: "admin" Read: you are successfully login terminal, expected. And I need to add a separate function handler handles a character return add to the each command above. If anyone can help this I can do the reset? Thank you in advance, John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0018.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SerialIO.java Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0018.pl From Steffen.DETTMER at ingenico.com Wed Aug 13 02:16:38 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 13 Aug 2008 10:16:38 +0200 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: References: Message-ID: <20080813081638.GA25412@elberon.bln.de.ingenico.com> * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > I can do like "login\n" in the string message to make character > return but I don't want to add this individual custom character > for each command return in every static message string I send, and why not?! > Can any who have done this might help me? what's about with writing a small wrapper function adding the carriage return? However, this would be slow, because either you call write two times (very bad) or the string needs to be copied, \n appended and written (since you are using Java Performance probably isn't so critical). Personally I would write `"login\n"' and `username + "\n"' etc., because since it is part of the command it should be part of the command definition string. > Basically, something like this,, Write and add function to the program write > a command, Reads the respond from a serial device.. correctly reading a `line' is more difficult. If you cannot make assumptions about timeouts and/or you need to have low delay, you need to read byte wise. If you need to save CPU resources you might need to add some buffering layer that you can read byte-wise but that is reading blockwise with some small timeout (lets say for serial lines something around byte transmission time times three or so). > /* > * To change this template, choose Tools | Templates > * and open the template in the editor. > */ :) > package joliba; > > /** > * > * @author root > */ :) > // derived from SUN's examples in the javax.comm package > import java.io.*; > import java.util.*; > //import javax.comm.*; // for SUN's serial/parallel port libraries > import gnu.io.*; // for rxtxSerial library > > public class SerialIO implements Runnable, SerialPortEventListener { > static CommPortIdentifier portId; > static CommPortIdentifier saveportId; > static Enumeration portList; > InputStream inputStream; > SerialPort serialPort; > Thread readThread; You need a thread for your synchronous RPC-style protocol? > static String messageString = "Hello, world!"; > static OutputStream outputStream; > static boolean outputBufferEmptyFlag = false; > > public static void main(String[] args) { > boolean portFound = false; > String defaultPort; > > // determine the name of the serial port on several operating systems > String osname = System.getProperty("os.name","").toLowerCase(); > if ( osname.startsWith("windows") ) { > // windows > defaultPort = "COM1"; > } else if (osname.startsWith("linux")) { > // linux > defaultPort = "/dev/ttyS0"; > } else if ( osname.startsWith("mac") ) { > // mac > defaultPort = "????"; > } else { > System.out.println("Sorry, your operating system is not supported"); > return; > } Is such a construction recommended? Isn't there some abstraction (like COM1 working on any platform)? [...] > try { > // activate the OUTPUT_BUFFER_EMPTY notifier > serialPort.notifyOnOutputEmpty(true); > } catch (Exception e) { > System.out.println("Error setting event notification"); > System.out.println(e.toString()); > System.exit(-1); > } I doubt that -1 is defined, probably some 127 or so would be the result, maybe better simply `throw e'? > public void writetoport() { > System.out.println("Writing \""+messageString+"\" to "+serialPort.getName()); > try { > // write string to serial port > outputStream.write(messageString.getBytes()); > } catch (IOException e) {} > } maybe something like /** * Writes the given output string and an additional carriage * return to the current outputStream. */ public void writeStringToPort( /** The output string (without CR). */ String output ) throws IOException { String outputLine = output + "\n"; outputStream.write(outputLine.getBytes()); } ? > > public SerialIO() { > // initalize serial port > try { > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > } catch (PortInUseException e) {} if the port is in use, you continue? Wonder that this works in Java, I would assume serialPort beeing uninitialized which AFAIK is an error in Java. > try { > inputStream = serialPort.getInputStream(); > } catch (IOException e) {} > > try { > serialPort.addEventListener(this); > } catch (TooManyListenersException e) {} > > // activate the DATA_AVAILABLE notifier > serialPort.notifyOnDataAvailable(true); > > try { > // set port parameters > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > } catch (UnsupportedCommOperationException e) {} > > // start the read thread > readThread = new Thread(this); > readThread.start(); > > } I think in all those exception cases you can abort, because it is unlikely that ignoring those errors allow a successful continuation, so in this case maybe it would be better to add a throw clause to the method. > public void run() { > // first thing in the thread, we initialize the write operation > initwritetoport(); > try { > while (true) { > // write string to port, the serialEvent will read it > writetoport(); > Thread.sleep(1000); > } > } catch (InterruptedException e) {} > } Does this make sense? Your `SimpleReadApp' writes one and the same string each second? > public void serialEvent(SerialPortEvent event) { > switch (event.getEventType()) { > case SerialPortEvent.BI: > case SerialPortEvent.OE: > case SerialPortEvent.FE: > case SerialPortEvent.PE: > case SerialPortEvent.CD: > case SerialPortEvent.CTS: > case SerialPortEvent.DSR: > case SerialPortEvent.RI: > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > break; > case SerialPortEvent.DATA_AVAILABLE: > // we get here if data has been received > byte[] readBuffer = new byte[20]; > try { > // read data > while (inputStream.available() > 0) { > int numBytes = inputStream.read(readBuffer); > } > // print data > String result = new String(readBuffer); > System.out.println("Read: "+result); > } catch (IOException e) {} I doubt that this is correct. I would assume you will get a 20 bytes result always, if more bytes would be available they would be printed in a second line but if less bytes are read I'd assume that the buffer/result contains zero bytes from implicite readBuffer contents initialisation (zero is no string terminator in Java AFAIK). > break; > } > } > } oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From florianmanschwetus at gmx.de Wed Aug 13 06:09:31 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 13 Aug 2008 14:09:31 +0200 Subject: [Rxtx] someone has seen such errors? Message-ID: <48A2CEFB.90007@gmx.de> I mean my communication mostly works, but it is far from perfect could this be the reason? Florian Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/949b9947/attachment-0018.bin From superdadusa at gmail.com Wed Aug 13 08:40:32 2008 From: superdadusa at gmail.com (John Choi) Date: Wed, 13 Aug 2008 08:40:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: <20080813081638.GA25412@elberon.bln.de.ingenico.com> References: <20080813081638.GA25412@elberon.bln.de.ingenico.com> Message-ID: Thank you so much Steffen and I will try that suggestion. John On 8/13/08, Steffen DETTMER wrote: > > * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > > I can do like "login\n" in the string message to make character > > return but I don't want to add this individual custom character > > for each command return in every static message string I send, > > and why not?! > > > Can any who have done this might help me? > > what's about with writing a small wrapper function adding the > carriage return? > However, this would be slow, because either you call write two > times (very bad) or the string needs to be copied, \n appended > and written (since you are using Java Performance probably isn't > so critical). > > Personally I would write `"login\n"' and `username + "\n"' etc., > because since it is part of the command it should be part of the > command definition string. > > > Basically, something like this,, Write and add function to the program > write > > a command, Reads the respond from a serial device.. > > correctly reading a `line' is more difficult. If you cannot make > assumptions about timeouts and/or you need to have low delay, you > need to read byte wise. If you need to save CPU resources you > might need to add some buffering layer that you can read > byte-wise but that is reading blockwise with some small timeout > (lets say for serial lines something around byte transmission > time times three or so). > > > /* > > * To change this template, choose Tools | Templates > > * and open the template in the editor. > > */ > > :) > > > package joliba; > > > > /** > > * > > * @author root > > */ > > :) > > > // derived from SUN's examples in the javax.comm package > > import java.io.*; > > import java.util.*; > > //import javax.comm.*; // for SUN's serial/parallel port libraries > > import gnu.io.*; // for rxtxSerial library > > > > public class SerialIO implements Runnable, SerialPortEventListener { > > static CommPortIdentifier portId; > > static CommPortIdentifier saveportId; > > static Enumeration portList; > > InputStream inputStream; > > SerialPort serialPort; > > Thread readThread; > > You need a thread for your synchronous RPC-style protocol? > > > static String messageString = "Hello, world!"; > > static OutputStream outputStream; > > static boolean outputBufferEmptyFlag = false; > > > > public static void main(String[] args) { > > boolean portFound = false; > > String defaultPort; > > > > // determine the name of the serial port on several operating > systems > > String osname = System.getProperty("os.name","").toLowerCase(); > > if ( osname.startsWith("windows") ) { > > // windows > > defaultPort = "COM1"; > > } else if (osname.startsWith("linux")) { > > // linux > > defaultPort = "/dev/ttyS0"; > > } else if ( osname.startsWith("mac") ) { > > // mac > > defaultPort = "????"; > > } else { > > System.out.println("Sorry, your operating system is not > supported"); > > return; > > } > > Is such a construction recommended? Isn't there some abstraction > (like COM1 working on any platform)? > > [...] > > try { > > // activate the OUTPUT_BUFFER_EMPTY notifier > > serialPort.notifyOnOutputEmpty(true); > > } catch (Exception e) { > > System.out.println("Error setting event notification"); > > System.out.println(e.toString()); > > System.exit(-1); > > } > > I doubt that -1 is defined, probably some 127 or so would be the > result, maybe better simply `throw e'? > > > public void writetoport() { > > System.out.println("Writing \""+messageString+"\" to > "+serialPort.getName()); > > try { > > // write string to serial port > > outputStream.write(messageString.getBytes()); > > } catch (IOException e) {} > > } > > maybe something like > > /** > * Writes the given output string and an additional carriage > * return to the current outputStream. > */ > public void > writeStringToPort( > /** The output string (without CR). */ > String output > ) throws IOException > { > String outputLine = output + "\n"; > outputStream.write(outputLine.getBytes()); > } > > ? > > > > > public SerialIO() { > > // initalize serial port > > try { > > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > > } catch (PortInUseException e) {} > > if the port is in use, you continue? Wonder that this works in > Java, I would assume serialPort beeing uninitialized which AFAIK > is an error in Java. > > > try { > > inputStream = serialPort.getInputStream(); > > } catch (IOException e) {} > > > > try { > > serialPort.addEventListener(this); > > } catch (TooManyListenersException e) {} > > > > // activate the DATA_AVAILABLE notifier > > serialPort.notifyOnDataAvailable(true); > > > > try { > > // set port parameters > > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > } catch (UnsupportedCommOperationException e) {} > > > > // start the read thread > > readThread = new Thread(this); > > readThread.start(); > > > > } > > I think in all those exception cases you can abort, because it is > unlikely that ignoring those errors allow a successful > continuation, so in this case maybe it would be better to add a > throw clause to the method. > > > public void run() { > > // first thing in the thread, we initialize the write operation > > initwritetoport(); > > try { > > while (true) { > > // write string to port, the serialEvent will read it > > writetoport(); > > Thread.sleep(1000); > > } > > } catch (InterruptedException e) {} > > } > > Does this make sense? Your `SimpleReadApp' writes one and the > same string each second? > > > public void serialEvent(SerialPortEvent event) { > > switch (event.getEventType()) { > > case SerialPortEvent.BI: > > case SerialPortEvent.OE: > > case SerialPortEvent.FE: > > case SerialPortEvent.PE: > > case SerialPortEvent.CD: > > case SerialPortEvent.CTS: > > case SerialPortEvent.DSR: > > case SerialPortEvent.RI: > > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > > break; > > case SerialPortEvent.DATA_AVAILABLE: > > // we get here if data has been received > > byte[] readBuffer = new byte[20]; > > try { > > // read data > > while (inputStream.available() > 0) { > > int numBytes = inputStream.read(readBuffer); > > } > > // print data > > String result = new String(readBuffer); > > System.out.println("Read: "+result); > > } catch (IOException e) {} > > I doubt that this is correct. I would assume you will get a 20 > bytes result always, if more bytes would be available they would > be printed in a second line but if less bytes are read I'd assume > that the buffer/result contains zero bytes from implicite > readBuffer contents initialisation (zero is no string terminator > in Java AFAIK). > > > break; > > } > > } > > } > > oki, > > Steffen > > About Ingenico Throughout the world businesses rely on Ingenico for secure > and expedient electronic transaction acceptance. Ingenico products leverage > proven technology, established standards and unparalleled ergonomics to > provide optimal reliability, versatility and usability. This comprehensive > range of products is complemented by a global array of services and > partnerships, enabling businesses in a number of vertical sectors to accept > transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged > information. If you are not the addressee or authorized to receive this for > the addressee, you must not use, copy, disclose or take any action based on > this message or any information herein. If you have received this message in > error, please advise the sender immediately by reply e-mail and delete this > message. Thank you for your cooperation. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/73c4135c/attachment-0017.html From ajmas at sympatico.ca Sat Aug 16 07:15:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 09:15:41 -0400 Subject: [Rxtx] someone has seen such errors? In-Reply-To: <48A2CEFB.90007@gmx.de> References: <48A2CEFB.90007@gmx.de> Message-ID: <43B5E8DA-1D93-4D90-809B-AAF35FF724C5@sympatico.ca> On 13-Aug-08, at 08:09 , Florian Manschwetus wrote: > I mean my communication mostly works, but it is far from perfect > could this be the reason? > > Florian > > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control Judging by the error messages this looks related to the driver you are using. Do a search for the following string with you favourite search engine, it should turn up a few hits: ftdi_set_termios FAILED to set databits/stopbits/parity Andre From ajmas at sympatico.ca Sat Aug 16 19:12:04 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 21:12:04 -0400 Subject: [Rxtx] Using SerialPortEvent? Message-ID: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Hi, Could someone tell me how I should be using the SerialPortEvent? Am I meant to be waiting for data and then simply reading from the inputstream? If this is the case why no just block on an inputstream read? Andr? From tjarvi at qbang.org Sat Aug 16 19:41:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 16 Aug 2008 19:41:13 -0600 (MDT) Subject: [Rxtx] Using SerialPortEvent? In-Reply-To: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> References: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Message-ID: On Sat, 16 Aug 2008, Andre-John Mas wrote: > Hi, > > Could someone tell me how I should be using the SerialPortEvent? Am I > meant to be waiting for data and then simply reading from the > inputstream? If this is the case why no just block on an inputstream > read? > Polling for data is fine also. It really depends upon what you are trying to do. For instance, if you require x bytes before reading, you can start polling after data is available. If you read on the same thread as your GUI and are waiting for data in a read, the results may be less than desirable. Java programming is 'usually' event driven rather than polling based. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sat Aug 16 20:10:39 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 22:10:39 -0400 Subject: [Rxtx] Using SerialPortEvent? In-Reply-To: References: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Message-ID: <3E495D4C-BB28-4845-A6AB-984C9A826BDF@sympatico.ca> On 16-Aug-08, at 21:41 , Trent Jarvi wrote: > On Sat, 16 Aug 2008, Andre-John Mas wrote: > >> Hi, >> >> Could someone tell me how I should be using the SerialPortEvent? Am I >> meant to be waiting for data and then simply reading from the >> inputstream? If this is the case why no just block on an inputstream >> read? >> > > Polling for data is fine also. It really depends upon what you are > trying to do. For instance, if you require x bytes before reading, > you can start polling after data is available. If you read on the > same thread as your GUI and are waiting for data in a read, the > results may be less than desirable. > > Java programming is 'usually' event driven rather than polling based. Sounds good. I thought I would use this opportunity to provide a event based version of the TwoWaySerialComm example. Could you just validate it before I add it to the Wiki: package ajmas74.experimental; import gnu.io.CommPort; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; import gnu.io.SerialPortEvent; import gnu.io.SerialPortEventListener; import java.io.IOException; import java.io.InputStream; import java.io.OutputStream; /** * This version of the TwoWaySerialComm example makes use of the * SerialPortEventListener to avoid polling. * * @author ajmas * */ public class TwoWaySerialComm { public TwoWaySerialComm() { super(); } void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { CommPort commPort = portIdentifier.open(this.getClass().getName(),2000); if ( commPort instanceof SerialPort ) { SerialPort serialPort = (SerialPort) commPort; serialPort .setSerialPortParams (57600 ,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); (new Thread(new SerialWriter(out))).start(); serialPort.addEventListener(new SerialReader(in)); } else { System.out.println("Error: Only serial ports are handled by this example."); } } } /** * Handles the input coming from the serial port. A new line character * is treated as the end of a block in this example. */ public static class SerialReader implements SerialPortEventListener { private InputStream in; private byte[] buffer = new byte[1024]; public SerialReader ( InputStream in ) { this.in = in; } public void serialEvent(SerialPortEvent arg0) { int data; try { int len = 0; while ( ( data = in.read()) > -1 ) { if ( data != '\n' ) { break; } buffer[len++] = (byte) data; } System.out.print(new String(buffer,0,len)); } catch ( IOException e ) { e.printStackTrace(); System.exit(-1); } } } /** */ public static class SerialWriter implements Runnable { OutputStream out; public SerialWriter ( OutputStream out ) { this.out = out; } public void run () { try { int c = 0; while ( ( c = System.in.read()) > -1 ) { this.out.write(c); } } catch ( IOException e ) { e.printStackTrace(); System.exit(-1); } } } public static void main ( String[] args ) { try { (new TwoWaySerialComm()).connect("COM3"); } catch ( Exception e ) { e.printStackTrace(); } } } From lfarkas at lfarkas.org Tue Aug 19 07:32:59 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Tue, 19 Aug 2008 15:32:59 +0200 Subject: [Rxtx] JNI or CNI Message-ID: <48AACB8B.9060606@lfarkas.org> hi, what is the current recommended way to rxtx on linux JNI or it's better to use CNI? is the CNI version fully functional and the same level as the JNI? i currently try to make a rhel/centos/fedora rpm for rxtx but has many problems with the standard dir structure. yours. -- Levente "Si vis pacem para bellum!" From lfarkas at lfarkas.org Tue Aug 19 08:47:34 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Tue, 19 Aug 2008 16:47:34 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel Message-ID: <48AADD06.7040809@lfarkas.org> hi, newer or not so newer linux kernel do not contain the UTS_RELEASE so the current rxtx is not compile on the latest kernels. even if it's commented out in the cvs configure there are other places. i attcahed a patch which fix it (or at least doesn't cause error at non-debug build). ps. is there any plan to the new 2.1-8 release in the near future? there are many changes (at least the license change in all file and in this case create a diff is very difficult)? the latest release more then 2 years old:-( -- Levente "Si vis pacem para bellum!" -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-2.1-uts.patch Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080819/ab5d38ac/attachment-0011.pl From ajmas at sympatico.ca Tue Aug 19 16:21:53 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 19 Aug 2008 18:21:53 -0400 Subject: [Rxtx] Event based example Message-ID: <24735BFB-B088-4B84-8173-FE98DF63B12F@sympatico.ca> Hi, I have just posted an example of using SerialPortEventListener in the Wiki: http://rxtx.qbang.org/wiki/index.php/Event_Based_Two_Way_Communication If you see any issues please could you let me know, or makes the changes. Andre From Martin.Oberhuber at windriver.com Fri Aug 22 04:02:24 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 22 Aug 2008 12:02:24 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <48AADD06.7040809@lfarkas.org> References: <48AADD06.7040809@lfarkas.org> Message-ID: <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> Farkas, there are indeed efforts to get a new RXTX release out the door. Your experience as a package maintainer would likely be helpful during these efforts, since I'd think it makes sense to keep the patches minimal that you must make to have the source compile in your environment. What are the things that you find problematic, apart from the UTS thing that you have mentioned before? What is the timing that you have in mind for your package? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Farkas Levente > Sent: Tuesday, August 19, 2008 4:48 PM > To: rxtx at qbang.org > Subject: [Rxtx] UTS_RELEASE not defined in newer kernel > > hi, > newer or not so newer linux kernel do not contain the > UTS_RELEASE so the > current rxtx is not compile on the latest kernels. even if it's > commented out in the cvs configure there are other places. > i attcahed a patch which fix it (or at least doesn't cause error at > non-debug build). > > ps. is there any plan to the new 2.1-8 release in the near > future? there > are many changes (at least the license change in all file and in this > case create a diff is very difficult)? the latest release more then 2 > years old:-( > > -- > Levente "Si vis pacem para bellum!" > From lfarkas at lfarkas.org Fri Aug 22 04:36:26 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Fri, 22 Aug 2008 12:36:26 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> References: <48AADD06.7040809@lfarkas.org> <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> Message-ID: <48AE96AA.6090505@lfarkas.org> hi, the packages already build for fedora-9 and centos-5 and here: http://www.lfarkas.org/linux/packages/ what i've to patch, the UTS, the configure script, but it's already fixed in the cvs (in another way) and the loadlibrary. the reasons for last one can be found here: https://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_files_that_use_JNI after we test it i'd like to add these packages to fedora and epel main repository (that's why it's be useful a new release after 2 years:-) imho versions are cheap and why not just release 2.1-8? the real code changes are minimal and if something critical bug found still can release 2.1-9:-) ps. and would be better to use simple number for version like 2.1-7 rather then 2.1-7v2. Oberhuber, Martin wrote: > Farkas, > > there are indeed efforts to get a new RXTX release out the > door. Your experience as a package maintainer would likely > be helpful during these efforts, since I'd think it makes > sense to keep the patches minimal that you must make to > have the source compile in your environment. > > What are the things that you find problematic, apart from > the UTS thing that you have mentioned before? > > What is the timing that you have in mind for your package? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >> On Behalf Of Farkas Levente >> Sent: Tuesday, August 19, 2008 4:48 PM >> To: rxtx at qbang.org >> Subject: [Rxtx] UTS_RELEASE not defined in newer kernel >> >> hi, >> newer or not so newer linux kernel do not contain the >> UTS_RELEASE so the >> current rxtx is not compile on the latest kernels. even if it's >> commented out in the cvs configure there are other places. >> i attcahed a patch which fix it (or at least doesn't cause error at >> non-debug build). >> >> ps. is there any plan to the new 2.1-8 release in the near >> future? there >> are many changes (at least the license change in all file and in this >> case create a diff is very difficult)? the latest release more then 2 >> years old:-( >> >> -- >> Levente "Si vis pacem para bellum!" >> -- Levente "Si vis pacem para bellum!" From tjarvi at qbang.org Fri Aug 22 18:50:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Aug 2008 18:50:32 -0600 (MDT) Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <48AE96AA.6090505@lfarkas.org> References: <48AADD06.7040809@lfarkas.org> <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> <48AE96AA.6090505@lfarkas.org> Message-ID: Hi Farkas, The v2 was simply the second build - no code changes. We are comming out with a new release shortly. I would encourage working with distros as you are. The building of rxtx turns out to be a bottle neck in quick releases. We do want stable releases that work for a year or more but I would have no problems with quicker cycles on developing work. I would have no problem working with someone that did builds that receive less testing more often but they do have to come out for multiple platforms from this end. Thanks for the links. On Fri, 22 Aug 2008, Farkas Levente wrote: > hi, > the packages already build for fedora-9 and centos-5 and here: > http://www.lfarkas.org/linux/packages/ > what i've to patch, the UTS, the configure script, but it's already > fixed in the cvs (in another way) and the loadlibrary. the reasons for > last one can be found here: > https://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_files_that_use_JNI > after we test it i'd like to add these packages to fedora and epel main > repository (that's why it's be useful a new release after 2 years:-) > imho versions are cheap and why not just release 2.1-8? the real code > changes are minimal and if something critical bug found still can > release 2.1-9:-) > > ps. and would be better to use simple number for version like 2.1-7 > rather then 2.1-7v2. > > Oberhuber, Martin wrote: >> Farkas, >> >> there are indeed efforts to get a new RXTX release out the >> door. Your experience as a package maintainer would likely >> be helpful during these efforts, since I'd think it makes >> sense to keep the patches minimal that you must make to >> have the source compile in your environment. >> >> What are the things that you find problematic, apart from >> the UTS thing that you have mentioned before? >> >> What is the timing that you have in mind for your package? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >>> On Behalf Of Farkas Levente >>> Sent: Tuesday, August 19, 2008 4:48 PM >>> To: rxtx at qbang.org >>> Subject: [Rxtx] UTS_RELEASE not defined in newer kernel >>> >>> hi, >>> newer or not so newer linux kernel do not contain the >>> UTS_RELEASE so the >>> current rxtx is not compile on the latest kernels. even if it's >>> commented out in the cvs configure there are other places. >>> i attcahed a patch which fix it (or at least doesn't cause error at >>> non-debug build). >>> >>> ps. is there any plan to the new 2.1-8 release in the near >>> future? there >>> are many changes (at least the license change in all file and in this >>> case create a diff is very difficult)? the latest release more then 2 >>> years old:-( >>> >>> -- >>> Levente "Si vis pacem para bellum!" >>> > > > From andy at triera.net Sat Aug 23 15:17:44 2008 From: andy at triera.net (Andy Rozman) Date: Sat, 23 Aug 2008 21:17:44 +0000 Subject: [Rxtx] port not identified on FreeBSD In-Reply-To: References: Message-ID: <48B07E78.2030306@triera.net> Hi ! I have one small problem... I have started using FreeBSD in last few days and I have come accross a problem with rxtx on FreeBSD. I am using usb-to-serial converter, which is identified under FreeBSD without problem as ucom0, and creates link under /dev called ttyU0, which is correct way to be done under FreeBSD (if device would be unidentified it would be called ugen0 - as usb generic). Problem is that I say to rxtx to get my all serial ports this one is not among them. Which names are permissable under linux-like implementations? Which will be accepted as serial ports? Andy From tjarvi at qbang.org Sat Aug 23 13:57:45 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 23 Aug 2008 13:57:45 -0600 (MDT) Subject: [Rxtx] port not identified on FreeBSD In-Reply-To: <48B07E78.2030306@triera.net> References: <48B07E78.2030306@triera.net> Message-ID: On Sat, 23 Aug 2008, Andy Rozman wrote: > Hi ! > > I have one small problem... I have started using FreeBSD in last few > days and I have come accross a problem with rxtx on FreeBSD. > > I am using usb-to-serial converter, which is identified under FreeBSD > without problem as ucom0, and creates link under /dev called > ttyU0, which is correct way to be done under FreeBSD (if device would be > unidentified it would be called ugen0 - as usb generic). Problem is that > I say to rxtx to get my all serial ports this one is not among them. > Which names are permissable under linux-like implementations? Which will > be accepted as serial ports? > > Andy > Thanks Andy! We will add ttyU* to FreeBSD. For now you can use properties to enable the port. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting#How_does_rxtx_detect_ports.3F__Can_I_override_it.3F The fix: diff -u -r1.16.2.59 RXTXCommDriver.java --- RXTXCommDriver.java 18 Nov 2007 22:32:41 -0000 1.16.2.59 +++ RXTXCommDriver.java 23 Aug 2008 19:55:25 -0000 @@ -644,6 +644,7 @@ { String[] Temp = { "ttyd", //general purpose serial ports + "ttyU", //general purpose USB serial ports "cuaa", //dialout serial ports "ttyA", //Specialix SI/XIO dialin ports "cuaA", //Specialix SI/XIO dialout ports -- Trent Jarvi tjarvi at qbang.org From rick_knight at rlknight.com Mon Aug 4 13:25:10 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Mon, 04 Aug 2008 12:25:10 -0700 Subject: [Rxtx] Sun's Comm API? Message-ID: <48975796.4010600@rlknight.com> I have an application that requires the javax compatible version of RXTX and Sun's comm api. I've been able to download and extract the version of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api anywhere. Can someone tell me where I can find it? Or maybe send me a copy? Also, when I try to build RXTX, configure and make complete successfully but make install failes with this error libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 I've never come accross this error before. How can I get past it? Thanks, Rick From bboyes at systronix.com Mon Aug 4 19:10:01 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:10:01 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48975796.4010600@rlknight.com> References: <48975796.4010600@rlknight.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/cb9c6167/attachment-0027.html From bboyes at systronix.com Mon Aug 4 19:12:37 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:12:37 -0600 Subject: [Rxtx] Towards an RXTX release - CSR BT/USB chipset In-Reply-To: <488FB7E7.8000802@gmail.com> References: <460801A4097E3D4CA04CC64EE648584806C56CF0@ism-mail03.corp.ad.wrs.com> <13557-75390@sneakemail.com> <20980-23424@sneakemail.com> <488FB7E7.8000802@gmail.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/52236088/attachment-0027.html From tjarvi at qbang.org Mon Aug 4 19:42:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 19:42:21 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: On Mon, 4 Aug 2008, Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: > I have an application that requires the javax compatible > version of RXTX > and Sun's comm api. I've been able to download and extract > the version > of RXTX that I need (2.0-7pre2) but I can't find Sun's camm > api > anywhere. Can someone tell me where I can find it? Or maybe > send me a > > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm port > support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have just > a ZIP with only the .class JAR file - no source or docs), has a readme > with these comments: > > This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release.? The 2.0.3 release itself is > no longer distributed.? comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project.? The RxTx project (http://www.rxtx.org ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org) was opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support.? Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins.? Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > ? > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > I hope that is helpful! > It would be nice to work with Sun to resolve those longstanding issues. But it may not be practical unless the process goes as fast and painless as the grandfathering of commapi did. Another option may be the old kaffe extensions that moved to gnu classpathx. These don't have the native libraries but should provide the 2.0 interface and the javax.comm.properties mechansim for SPI. http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Mon Aug 4 20:23:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Mon, 04 Aug 2008 20:23:57 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4897B9BD.5070809@ergotech.com> Has there been any work/would it be possible, to layer a javacomm look-alike on top of the GNU code? The goal is not to move the javax code forward, but to emulate the "legacy" javax packages for people who still need this. Jim Trent Jarvi wrote: > On Mon, 4 Aug 2008, Bruce Boyes wrote: > >> At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible >> version of RXTX >> and Sun's comm api. I've been able to download and extract >> the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm >> api >> anywhere. Can someone tell me where I can find it? Or maybe >> send me a >> >> >> javaxcomm has had a sort of on-again off-again history. The windoze >> version has been languishing for years (literally) but there are newer >> versions for other OS's. >> >> We try to keep links on one of our help pages current: >> http://www.practicalembeddedjava.com/tools/javatools_list.html >> which gets you to here: >> http://java.sun.com/products/javacomm/ >> where it says in fact they no longer even support Windows and Mac: >> "Implementations of the API are currently available for Solaris SPARC, >> Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so >> someone could support it. But I guess that's part of the reason RXTX >> exists! >> >> So one of Sun's own products, SunSPOT, has to use RXTX to get comm port >> support. >> >> The version we use is 2.0 from 11/15/1998. I have posted it on our >> website, which is within the terms of the license agreement contained >> therein (as I understand it). >> >> The last version of javaxcomm for Windows, 2.0.3, (for which I have just >> a ZIP with only the .class JAR file - no source or docs), has a readme >> with these comments: >> >> This distribution contains the comm.jar file original part >> of the COMMAPI 2.0.3 release. The 2.0.3 release itself is >> no longer distributed. comm.jar, which contains the comm >> API java class files (eg. Sun's binary implementation of the >> interface classes), is being made available, unsupported, >> with no obligation to fix bugs, at the request of the RXTX >> project. The RxTx project (http://www.rxtx.org ), uses the >> comm.jar class files, but provides their own native library >> components to provide support for other platforms. >> >> The 2.0.3 comm.jar is being provided in this way because >> as of COMMAPI 3.x, the java binary implementation forked and >> became incompatible with the RxTx project's native code. >> Due to the lack of a clear business case, and to resource >> constraints, no additional resources are being >> provided to provide an alternative engineering solution >> at the time of writing. >> >> RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: >> >> Ultimately the COMMAPI would be better served if a Java >> Community Process JSR (http://www.jcp.org) was opened and >> the COMMAPI was rearchitected to provide a more pluggable >> framework to improve cross-platform support. Such an >> architecture would embody a better defined and better >> documented SPI interface, including a way for comm. ports >> to be revealed to the client application through the API >> via platform-aware plugins. Similarly, native code used >> to access comm port in general could be handled more >> flexibly using a plugin model, whereby on any platform, >> multiple native modules could be in use simultaneously. >> >> Since there are now various ways serial ports can be implemented >> and accessed, modular comm. port JNI native libraries would be >> of benefit insofar as removing the burden of over-generalization >> from any single native component, or inversely, by relieving the >> implicit constraint that comm. drivers be accessed only via a >> monolithic mechanism, such as the UNIX vnode interface. >> >> paul.klissner at sun.com >> 6/10/06 >> >> I hope that is helpful! >> > > It would be nice to work with Sun to resolve those longstanding issues. > But it may not be practical unless the process goes as fast and painless > as the grandfathering of commapi did. > > Another option may be the old kaffe extensions that moved to gnu > classpathx. These don't have the native libraries but should provide > the 2.0 interface and the javax.comm.properties mechansim for SPI. > > http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Mon Aug 4 21:09:15 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 21:09:15 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? Message-ID: Hi Jim, I will not step into the javax.comm namespace without Sun's explicite permission. I fully understand the pain point you are trying to address. In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm Linux) - which remains an integral part of rxtx. At the time it was a win for Sun and rxtx. The Sun commapi license is/was fairly clear that rxtx should not step into that namespace. It made sense as Sun was active in that space and rxtx may go into another namespace - it was an experiment in working with Sun. This may sound silly looking at something that happened almost 10 years ago. In a community of respect which Sun helped create, there is no question about what to do. I hope eventually Sun will step up and do a right thing too. I agree that this is hurting the API more than helping it. There are also questions about how to replace the API in the long term which includes HID support which isn't going well so far. Others that can't even look at Sun's javax.comm today and can look at Kaffe's contribution to classpathx can easily work around such restrictions. On Mon, 4 Aug 2008, Jim Redman wrote: > Has there been any work/would it be possible, to layer a javacomm > look-alike on top of the GNU code? > > The goal is not to move the javax code forward, but to emulate the > "legacy" javax packages for people who still need this. > > Jim > > Trent Jarvi wrote: >> >> It would be nice to work with Sun to resolve those longstanding issues. >> But it may not be practical unless the process goes as fast and painless >> as the grandfathering of commapi did. >> >> Another option may be the old kaffe extensions that moved to gnu >> classpathx. These don't have the native libraries but should provide >> the 2.0 interface and the javax.comm.properties mechansim for SPI. >> >> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From florianmanschwetus at gmx.de Tue Aug 5 05:04:46 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 13:04:46 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: References: <48971C1F.9020806@gmx.de> Message-ID: <489833CE.1040801@gmx.de> Just look at sendCommand in this method I have to place a Thread.sleep(20) after each byte send to get working. Even the event based receive doesn't work fine but this could be may stupidness. The specifikation document (it is on the last pages of the manual) for the beamer could be found on: http://www.optoma.co.uk/support.aspx Florian Manschwetus Trent Jarvi schrieb: > > Hi Florian > > Sorry for the top post in advance. I worry you may not see my answer > under all your code :) > > I have not received this email before. This is 500k of code which I > don't have time to read. I can spend about 5 min on each hobby email > and still get to work in the morning. I have a couple suggestions for > how to get an answer. > > First, cut out your comments and extra code so you can demonstrate the > question (I might even glance and see what is wrong then). Don't go for > a working final product. Isolate the problem using a simple program and > then ask with that as an example. If I did what you just did, I'd have > to post 3/4 of a million lines of code :) > > Second, join the rxtx mail-list and ask there. This will give you 100x > more eyes. I'll also read and try to follow. > > -- > taj > > > > On Mon, 4 Aug 2008, Florian Manschwetus wrote: > >> It could be that my university account is blocked by filters so >> resending from here. >> >> >> Topic is to control Optoma HD80 beamer using rs232 serial chat. >> This code is able to detect power state and switch the beamer on / off. >> connected is the beamer using a digitus usb 2.0 serial adapter with an >> FT232 USB-Serial adapter the systems architecture is amd64. >> >> Please take a look in the sendCommand routine i have to place theire >> those Thread.sleep to get it working. >> Now the question is this correct or is there a better way to get this >> working correctly? >> >> In the javadoc coming with the install i found this: >> setBaudBase >> >> public boolean setBaudBase(int BaudBase) >> throws UnsupportedCommOperationException, >> java.io.IOException >> >> Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 >> before using. >> >> could this explain the error? >> I attached my java source and the protocol description for the beamer >> (available on vendor website). >> >> thx, >> Florian Manschwetus >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: TestRS232.java Type: text/x-java Size: 9143 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0054.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0055.bin From michael.erskine at ketech.com Tue Aug 5 05:53:49 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Tue, 5 Aug 2008 12:53:49 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489833CE.1040801@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> > Just look at sendCommand in this method I have to place a > Thread.sleep(20) after each byte send to get working. Even the event > based receive doesn't work fine but this could be may stupidness. Hi Florian, Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. Regards, Michael Erskine. From florianmanschwetus at gmx.de Tue Aug 5 07:28:15 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:28:15 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> Message-ID: <4898556F.8000208@gmx.de> Michael Erskine schrieb: >> Just look at sendCommand in this method I have to place a >> Thread.sleep(20) after each byte send to get working. Even the event >> based receive doesn't work fine but this could be may stupidness. > > Hi Florian, > > Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. > > Regards, > Michael Erskine. > Ok, sounds fine for the receiving problem. But why i have to wait after each byte when sending a command squence? (the for loop in send command) Florian > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/284f350c/attachment-0026.bin From florianmanschwetus at gmx.de Tue Aug 5 07:44:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:44:14 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <4898592E.2020908@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >>> Just look at sendCommand in this method I have to place a >>> Thread.sleep(20) after each byte send to get working. Even the event >>> based receive doesn't work fine but this could be may stupidness. >> >> Hi Florian, >> >> Yes, naturally you'll have to wait for a response from the other end. >> Why not wait for notification from the event thread perhaps using a >> BlockingDeque rather than your LinkedList. Generally I >> try to decouple all input and output streams: in your case your >> application is operating synchronously like the "expect" program >> (http://expect.nist.gov/) so waits (or timeouts) will need to be >> factored in. >> >> Regards, >> Michael Erskine. >> > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) > > Florian Furthermore there is this basic baud with this confusing javadoc entry: public boolean setBaudBase(int BaudBase) throws UnsupportedCommOperationException, java.io.IOException Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 before using. maybe this could explain something Florian >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/006c7425/attachment-0026.bin From jredman at ergotech.com Tue Aug 5 09:13:36 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 05 Aug 2008 09:13:36 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: Message-ID: <48986E20.3060104@ergotech.com> Trent, So two issues: 1) Technically I'm still not sure how easy/practical a layer would be. The problems are always classes like listeners, and wrapping returns of gnu.io classes. I really see it as a "delegate" type of concept. Any thoughts or ideas of the practicality of this approach? The idea is not to modify RXTX. 2) Javax. The javax namespace does seem to be in widespread use outside of Sun (the same is true for the java namespace). The classpath extensions, or some other location, should be interested in a JavaComm implementation even if it does have dependencies on RXTX. Would you have any philosophical objection to an approach like that? Of course, I suspect it might be better if someone with that authority at Sun would admit that the javax namespace is already in the wild and that there is no problem with it being used within RXTX. Jim Trent Jarvi wrote: > Hi Jim, > > I will not step into the javax.comm namespace without Sun's explicite > permission. I fully understand the pain point you are trying to address. > > In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm > Linux) - which remains an integral part of rxtx. At the time it was a win for > Sun and rxtx. > > The Sun commapi license is/was fairly clear that rxtx should not step into that > namespace. It made sense as Sun was active in that space and rxtx may go into > another namespace - it was an experiment in working with Sun. > > This may sound silly looking at something that happened almost 10 years ago. > In a community of respect which Sun helped create, there is no question about > what to do. I hope eventually Sun will step up and do a right thing too. > > I agree that this is hurting the API more than helping it. There are also > questions about how to replace the API in the long term which includes HID > support which isn't going well so far. > > Others that can't even look at Sun's javax.comm today and can look at Kaffe's > contribution to classpathx can easily work around such restrictions. > > On Mon, 4 Aug 2008, Jim Redman wrote: > >> Has there been any work/would it be possible, to layer a javacomm >> look-alike on top of the GNU code? >> >> The goal is not to move the javax code forward, but to emulate the >> "legacy" javax packages for people who still need this. >> >> Jim >> >> Trent Jarvi wrote: >>> It would be nice to work with Sun to resolve those longstanding issues. >>> But it may not be practical unless the process goes as fast and painless >>> as the grandfathering of commapi did. >>> >>> Another option may be the old kaffe extensions that moved to gnu >>> classpathx. These don't have the native libraries but should provide >>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>> >>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From sandeep at genevasoftech.com Tue Aug 5 11:18:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Tue, 05 Aug 2008 22:48:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <48988B6C.5080409@genevasoftech.com> Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. *-- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/ad20f1cb/attachment-0026.html From Martin.Oberhuber at windriver.com Tue Aug 5 13:30:17 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Tue, 5 Aug 2008 21:30:17 +0200 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Sandeep, shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on Sol7 but I've successfully run it on Sol9 and Sol10. Or is your request really about a native 64bit variant? I'm afraid that then you're out of luck since I think that quite a bit of RXTX is not yet ready for 64 bit. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Sandeep Kumar K Sent: Tuesday, August 05, 2008 7:19 PM To: rxtx at qbang.org Subject: [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so for Solaris 9 Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. -- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/81b7f988/attachment-0026.html From tjarvi at qbang.org Tue Aug 5 22:38:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 22:38:34 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 5 Aug 2008, Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built > on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid that > then > you're out of luck since I think that quite a bit of RXTX is not yet > ready > for 64 bit. > While rxtx-2.1-7 probably has problems, The CVS code should be OK for 64 bit Solaris. If it isn't, let me know and I'll find which patch is missing. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Aug 5 23:13:00 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 23:13:00 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48986E20.3060104@ergotech.com> References: <48986E20.3060104@ergotech.com> Message-ID: On Tue, 5 Aug 2008, Jim Redman wrote: > Trent, > > So two issues: > > 1) Technically I'm still not sure how easy/practical a layer would be. The > problems are always classes like listeners, and wrapping returns of gnu.io > classes. I really see it as a "delegate" type of concept. Any thoughts or > ideas of the practicality of this approach? The idea is not to modify RXTX. I have not put too much thought into this. I assume you want what rxtx 2.0 provided to tie into javax.comm implementations. More classes could be added to rxtx 2.1-7 for SPI support. Maintaining rxtx-2.0 could also be handed to someone if they like. > > 2) Javax. The javax namespace does seem to be in widespread use outside of > Sun (the same is true for the java namespace). The classpath extensions, or > some other location, should be interested in a JavaComm implementation even > if it does have dependencies on RXTX. Would you have any philosophical > objection to an approach like that? > No problems. Classpathx would be a possible place to do it. I'd suggest thinking twice about what this involves in practical terms. You would be wanting to revive the 2.0 API while Sun is at 3.0 and grandfathering the JSR. This undermines the main reason (established api) for using the javax.comm namespace and does not leave such a project in a good position. The only win I see here is maintaining support for applications that can't migrate namespaces. Not that that isn't important. At some point it is going to be less work to just edit the bytecode :) Such a javax.comm effort would also be signing up new projects that decided to use the work up for concerns they probably will not understand or expect. That probably isn't a good path to facilitate for new projects at this time. We will put a good faith effort to work well with others but keep in mind the project has limited bandwidth for such efforts. > Of course, I suspect it might be better if someone with that authority at Sun > would admit that the javax namespace is already in the wild and that there is > no problem with it being used within RXTX. > > Jim > > Trent Jarvi wrote: >> Hi Jim, >> >> I will not step into the javax.comm namespace without Sun's explicite >> permission. I fully understand the pain point you are trying to address. >> >> In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java >> Comm Linux) - which remains an integral part of rxtx. At the time it was a >> win for Sun and rxtx. >> >> The Sun commapi license is/was fairly clear that rxtx should not step into >> that namespace. It made sense as Sun was active in that space and rxtx may >> go into another namespace - it was an experiment in working with Sun. >> >> This may sound silly looking at something that happened almost 10 years >> ago. In a community of respect which Sun helped create, there is no >> question about what to do. I hope eventually Sun will step up and do a >> right thing too. >> >> I agree that this is hurting the API more than helping it. There are also >> questions about how to replace the API in the long term which includes HID >> support which isn't going well so far. >> >> Others that can't even look at Sun's javax.comm today and can look at >> Kaffe's contribution to classpathx can easily work around such >> restrictions. >> >> On Mon, 4 Aug 2008, Jim Redman wrote: >> >>> Has there been any work/would it be possible, to layer a javacomm >>> look-alike on top of the GNU code? >>> >>> The goal is not to move the javax code forward, but to emulate the >>> "legacy" javax packages for people who still need this. >>> >>> Jim >>> >>> Trent Jarvi wrote: >>>> It would be nice to work with Sun to resolve those longstanding issues. >>>> But it may not be practical unless the process goes as fast and painless >>>> as the grandfathering of commapi did. >>>> >>>> Another option may be the old kaffe extensions that moved to gnu >>>> classpathx. These don't have the native libraries but should provide >>>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>>> >>>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From sandeep at genevasoftech.com Wed Aug 6 00:03:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Wed, 06 Aug 2008 11:33:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: <48993EB8.30107@genevasoftech.com> Thank you Mr. Martin for your suggestion. The native file which is given in rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am getting the following error . Any suggestions to solve this issue. I am using Solaris SPARC 64 bit machine. ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) thrown while loading gnu.io.RXTXCommDriver Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(Unknown Source) at java.lang.ClassLoader.loadLibrary(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) at com.ReadFromModem.main(ReadFromModem.java:84) * * *Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid > that then > you're out of luck since I think that quite a bit of RXTX is not yet ready > for 64 bit. > > Cheers, > -- > *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > ------------------------------------------------------------------------ > *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On > Behalf Of *Sandeep Kumar K > *Sent:* Tuesday, August 05, 2008 7:19 PM > *To:* rxtx at qbang.org > *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so > for Solaris 9 > > Hi, > > Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 > bit machine. The librxtxSerial.so given in website is for Solaris 8. > > *-- > > Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/1e920343/attachment-0026.html From tjarvi at qbang.org Wed Aug 6 00:21:42 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 00:21:42 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <48993EB8.30107@genevasoftech.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> <48993EB8.30107@genevasoftech.com> Message-ID: Hi Sandeep You may be out of luck unless you can compile the 2.1 src in CVS (requires gnu make and gcc). But you could try the ToyBox(R)(TM) which is a collection of WiLdLy untested cross compiled 2.1-7 binaries covering everything from the ibm z series to embeded arm/ppc. To give an idea how poorly these are tested, I don't even know if z series machines have a serial port. ftp://www.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Solaris They should at least match the binary types. Actually, I think if you use the rxtx jar from CVS with that file, it should 'work' as the fix for 64 bits was in java not the native code. You could just cd rxtx*/src; javac *.java then jar -cf RXTXcomm.jar `find -name \*.class` to create the hybrid which will complain about version information a bit. On Wed, 6 Aug 2008, Sandeep Kumar K wrote: > Thank you Mr. Martin for your suggestion. The native file which is given in > rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am > getting the following error . > Any suggestions to solve this issue. > I am using Solaris SPARC 64 bit machine. > > ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar > java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 > (Possible cause: architecture word > width mismatch) thrown while loading gnu.io.RXTXCommDriver > Exception in thread "main" java.lang.UnsatisfiedLinkError: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF > class: ELFCLASS64 (Possible cause: > architecture word width mismatch) > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(Unknown Source) > at java.lang.ClassLoader.loadLibrary(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > at com.ReadFromModem.main(ReadFromModem.java:84) > > * > * > > *Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > > > Oberhuber, Martin wrote: >> Sandeep, >> shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse >> variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on >> Sol7 but I've successfully run it on Sol9 and Sol10. >> Or is your request really about a native 64bit variant? I'm afraid that >> then >> you're out of luck since I think that quite a bit of RXTX is not yet ready >> for 64 bit. >> Cheers, >> -- >> *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> ------------------------------------------------------------------------ >> *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On >> Behalf Of *Sandeep Kumar K >> *Sent:* Tuesday, August 05, 2008 7:19 PM >> *To:* rxtx at qbang.org >> *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so >> for Solaris 9 >> >> Hi, >> >> Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 >> bit machine. The librxtxSerial.so given in website is for Solaris 8. >> >> *-- >> Thanks & Regards >> >> Sandeep Kumar K >> Sr. Software Engineer >> Geneva Software Technologies >> Whitefield, Bangalore >> Mob : 9880193454* >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> From michael.erskine at ketech.com Wed Aug 6 01:39:28 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 6 Aug 2008 08:39:28 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Florian Manschwetus wrote: > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) Hi Florian, I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. Regards, Michael Erskine. From florianmanschwetus at gmx.de Wed Aug 6 02:53:16 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 06 Aug 2008 10:53:16 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Message-ID: <4899667C.6010706@gmx.de> Michael Erskine schrieb: > Florian Manschwetus wrote: >> Ok, sounds fine for the receiving problem. >> But why i have to wait after each byte when sending a command squence? >> (the for loop in send command) > > Hi Florian, > I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. > > Regards, > Michael Erskine. > correct with a terminal on the other end it works, my idea was that this basic baud has some influence. Could some one explain what it is for? Florian > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/c2b4fa84/attachment-0026.bin From rick_knight at rlknight.com Wed Aug 6 13:01:07 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:01:07 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F4F3.3020707@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > I have an application (Readerware) that uses RXTX with Javax to access the serial port. This used to work fine under previous Linux' and Java, but something has changed, I assume with Java itself , that is causing the application to fail with a link error. The application is not able to find librxtxSerialParallel.so. RXTX supplies librxtxSerial.so and librxtxParallel.so, but not librxtxSerialParallel.so. Where can I get librxtxSerialParallel.so, or do I need it? Is something else causing the lib to not be found? Thanks, Rick Knight From rick_knight at rlknight.com Wed Aug 6 13:17:55 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:17:55 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F8E3.5060400@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Thanks for the reply. The developer of the app I'm trying to use (Readerware) has sent me a copy of the comm.api and I've copied the library (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar into the proper places. When I try to run the application, I get this error... Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: /usr/lib/libSolarisSerialParallel.so: /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not little-endian (Possible cause: endianness mismatch) Caught java.lang.UnsatisfiedLinkError: com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I while loading driver com.sun.comm.SolarisDriver Is there a way around this error? Thanks again, Rick Knight From jlar310 at gmail.com Wed Aug 6 13:37:42 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 14:37:42 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899F8E3.5060400@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > The developer of the app I'm trying to use (Readerware) has sent me a > copy of the comm.api and I've copied the library > (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar > into the proper places. When I try to run the application, I get this > error... > > Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: > /usr/lib/libSolarisSerialParallel.so: > /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not > little-endian (Possible cause: endianness mismatch) > Caught java.lang.UnsatisfiedLinkError: > com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I > > while loading driver com.sun.comm.SolarisDriver > > Is there a way around this error? What host OS are you running? From your original post it looks like 32 bit Linux. The libSolarisSerialParallel.so file is for Sun Solaris and will vary depending on the underlying hardware architecture as well. Sorry for the double post Rick, but I failed to send this to the list the first time... -- Jeff From rick_knight at rlknight.com Wed Aug 6 13:44:29 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:44:29 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: <4899FF1D.9030504@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > > >> The developer of the app I'm trying to use (Readerware) has sent me a >> copy of the comm.api and I've copied the library >> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >> into the proper places. When I try to run the application, I get this >> error... >> >> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >> /usr/lib/libSolarisSerialParallel.so: >> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >> little-endian (Possible cause: endianness mismatch) >> Caught java.lang.UnsatisfiedLinkError: >> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >> >> while loading driver com.sun.comm.SolarisDriver >> >> Is there a way around this error? >> > > What host OS are you running? From your original post it looks like 32 > bit Linux. > > The libSolarisSerialParallel.so file is for Sun Solaris and will vary > depending on the underlying hardware architecture as well. > > I'm running Kubuntu Linux (debian based). It's 32 bit. Rick Knight From jlar310 at gmail.com Wed Aug 6 15:33:23 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 16:33:23 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > I don't think Sun did binary libraries for Linux in the 2.0 version. Can someone with more historical experience than I confirm that? I recently tried to port a Comm API application from Solaris sparc to Linux x86 and likewise could not get my hands on the binary libraries. I eventually just re-wrote the code to use the gnu namespace packages and rxtx 2.1. What I don't understand is why your application vendor does not provide everything you need to run their software. FYI: I have librxtxParallel.so and librxtxSerial.so installed at JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is /usr/java/default which is actually a softlink to /usr/java/jre1.6.0_05. -- Jeff From defiantlew at yahoo.com.au Wed Aug 6 16:29:33 2008 From: defiantlew at yahoo.com.au (Lew L) Date: Thu, 7 Aug 2008 08:29:33 +1000 Subject: [Rxtx] Sun's Comm API Documentation References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> Message-ID: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> As a matter of interest is the Sun Comm API documentation available somewhere? I have tried the Sun site but it seems to have been removed. Unless I have missed the documentation for RXTX? I javadocced the RXTX source but information (to me) is minimal. Somewhere I got the impression that the Sun Comm API docs is, or was, compatible with RXTX, what is the best docs to use in conjuntion with RXTX and where may the be available? Cheers Lew From rick_knight at rlknight.com Wed Aug 6 17:18:33 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:18:33 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A3149.4050306@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff I'm not sure if I posted this here or not, but when I try to build RXTX from source I get this install error... make all-am make[1]: Entering directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' make[1]: Nothing to be done for `all-am'. make[1]: Leaving directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 Can you tell me how to get past this error and get RXTX built and installed? Thanks, Rick From bboyes at systronix.com Wed Aug 6 17:40:12 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Wed, 06 Aug 2008 17:40:12 -0600 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: At 16:29 08/06/2008, Lew L wrote: >As a matter of interest is the Sun Comm API documentation available >somewhere? I have tried the Sun site but it seems to have been removed. It's in the file we have posted, link in prev email (sorry, in a huge hurry right now). Javadocs definitely there. >Unless I have missed the documentation for RXTX? I javadocced the RXTX >source but information (to me) is minimal. >Somewhere I got the impression that the Sun Comm API docs is, or was, >compatible with RXTX, what is the best docs to use in conjuntion with RXTX >and where may the be available? Yeah, this is one of my concerns/beefs. There is little documentation for RXTX and it isn't just the same as javaxcomm. I would be willing to help out writing docs for RXTX! Yes really... esp if we can fix the Bluetooth issues. best regards Bruce >Cheers >Lew > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx ------- WWW.SYSTRONIX.COM ---------- Real embedded Java and much more +1-801-534-1017 Salt Lake City, USA From rick_knight at rlknight.com Wed Aug 6 17:54:08 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:54:08 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A39A0.2090309@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff, I would like for my vendor to switch to rxtx 2.1. It would make things much easier for me. I'm not sure why he's still using the javax compatible code. He's a small operation. Re-writing the code to use gnu namespace sounds like a major overhaul. Was it? Thanks, Rick From tjarvi at qbang.org Wed Aug 6 21:35:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:35:12 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: >> >>> Jeff wrote: >>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>>> >>>> >>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things > much easier for me. I'm not sure why he's still using the javax > compatible code. He's a small operation. Re-writing the code to use gnu > namespace sounds like a major overhaul. Was it? > Hi Jeff, The changes are fairly mechanical. Imports need to change and any explicite use of the namespace needs to change such as catching an exception. The following script was made for maintaining rxtx 2.0 but can apply to other needs. It is in the contrib dir with rxtx source. #!/bin/sh # Don't use! :) # # Sat, 03 May 2003 16:45:08 Modifications from J?rg Weule # Create a ed-cmd for the change of one pattern # case $1 in gnu) X=g/javax_comm/s+javax_comm+gnu_io+g ;; javax) X=g/gnu_io/s+gnu_io+javax_comm+g ;; *) echo;echo;echo From the top rxtx directory run;echo;echo -e \\t./ChangePackage.sh gnu;echo -e \\t\\tor;echo -e \\t./ChangePackage.sh javax;echo;echo; exit 0 ;; esac # # ed will be used to keep the owner and mode of the files unchanged. # We have run the ed-script for the characters '.' '/' as well. # "tr _ $D" do the change. # find . -type f -a -print | grep -v $0 | (while read F ; do ( echo $X; echo $X| tr _ /; echo $X| tr _ .; echo w; echo q ) | ed $F 2>&1 >/dev/null done ) # # Now we do little changes at the Makefiles. Hope that all we need. # find . -name Makefile\* -a -print | (while read F ; do cat < References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: On Thu, 7 Aug 2008, Lew L wrote: > As a matter of interest is the Sun Comm API documentation available > somewhere? I have tried the Sun site but it seems to have been removed. > > Unless I have missed the documentation for RXTX? I javadocced the RXTX > source but information (to me) is minimal. > Somewhere I got the impression that the Sun Comm API docs is, or was, > compatible with RXTX, what is the best docs to use in conjuntion with RXTX > and where may the be available? > Hi Lew, The documentation on Sun's website is accurate. The changes that are problematic in 3.0 are on the backside which rxtx used to plug into. http://java.sun.com/products/javacomm/reference/api/index.html CommPortIdentifier may have some minor differences (judging by the authors notes). -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Aug 6 21:46:08 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:46:08 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > If javax.comm.properties is properly installed and you are using a 2.0 version of Sun's commapi with rxtx 2.0, you should not see the library attempt to load libSolarisSerialParallel.so. Sun CommAPI 3.0 will not work with any version of rxtx as it is hard coded to use the shared library. See the INSTALL file with rxtx-2.0 source for more help with the properties file. -- Trent Jarvi tjarvi at qbang.org From jlar310 at gmail.com Thu Aug 7 06:32:06 2008 From: jlar310 at gmail.com (Jeff) Date: Thu, 7 Aug 2008 07:32:06 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > Jeff wrote: >> >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >> wrote: >> >>> >>> Jeff wrote: >>> >>>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>> wrote: >>>> >>>> >>>> >>>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things much > easier for me. I'm not sure why he's still using the javax compatible code. > He's a small operation. Re-writing the code to use gnu namespace sounds like > a major overhaul. Was it? I found it quite easy. In fact, in order to accommodate the transition, I actually separated all of the code that deals directly with the Comm API or RXTX into a helper class. The helper class was then coded to use reflection to determine which library was available and then instantiate the necessary objects. No direct imports of either library are used. The main application just needs to get it's hands on the IO streams and need not deal directly with the libraries. Other programs may not be so simple... But this doesn't really help you unless your vendor forks over the source code... -- Jeff From rick_knight at rlknight.com Thu Aug 7 09:47:12 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Thu, 07 Aug 2008 08:47:12 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: <489B1900.10108@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >>> wrote: >>> >>> >>>> Jeff wrote: >>>> >>>> >>>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>>> copy of the comm.api and I've copied the library >>>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>>> into the proper places. When I try to run the application, I get this >>>>>> error... >>>>>> >>>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>>> /usr/lib/libSolarisSerialParallel.so: >>>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>>> little-endian (Possible cause: endianness mismatch) >>>>>> Caught java.lang.UnsatisfiedLinkError: >>>>>> >>>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>>> >>>>>> while loading driver com.sun.comm.SolarisDriver >>>>>> >>>>>> Is there a way around this error? >>>>>> >>>>>> >>>>>> >>>>> What host OS are you running? From your original post it looks like 32 >>>>> bit Linux. >>>>> >>>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>>> depending on the underlying hardware architecture as well. >>>>> >>>>> >>>>> >>>>> >>>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>>> >>>> >>>> >>> I don't think Sun did binary libraries for Linux in the 2.0 version. >>> Can someone with more historical experience than I confirm that? >>> >>> I recently tried to port a Comm API application from Solaris sparc to >>> Linux x86 and likewise could not get my hands on the binary libraries. >>> I eventually just re-wrote the code to use the gnu namespace packages >>> and rxtx 2.1. >>> >>> What I don't understand is why your application vendor does not >>> provide everything you need to run their software. >>> >>> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >>> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >>> /usr/java/default which is actually a softlink to >>> /usr/java/jre1.6.0_05. >>> >>> >>> >> Jeff, >> >> I would like for my vendor to switch to rxtx 2.1. It would make things much >> easier for me. I'm not sure why he's still using the javax compatible code. >> He's a small operation. Re-writing the code to use gnu namespace sounds like >> a major overhaul. Was it? >> > > I found it quite easy. In fact, in order to accommodate the > transition, I actually separated all of the code that deals directly > with the Comm API or RXTX into a helper class. The helper class was > then coded to use reflection to determine which library was available > and then instantiate the necessary objects. No direct imports of > either library are used. The main application just needs to get it's > hands on the IO streams and need not deal directly with the libraries. > Other programs may not be so simple... > > But this doesn't really help you unless your vendor forks over the > source code... > > Jeff, This may not help me directly, but I'm going to forward this thread to the vendor. I think he'll be open to making things work. Thanks again, Rick Knight From agusmunioz at gmail.com Thu Aug 7 16:39:51 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Thu, 7 Aug 2008 19:39:51 -0300 Subject: [Rxtx] How to send ack? Message-ID: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Hi, I'm still learning about serial communication and I have some doubts. I've got this question about how to do the following thing in rxtx. I have this hardware that connect to a PC using a serial port. These hardware receives data from a telephone line, proccess it, and then send it forward to the serial port. I've used a program named wincomm that shows what information is send it through the serial port and I have the nex behaviour: The hardware has a buffer where all data is stored, that cannot be sent it through the seria port. The program reads the first data send it by the hardware, and keep reading the same data always. There is a button in the application that says enable Ack, and when I click, then the hardware start to send all the stored information, and all the information is shown. I write a class, using rxtx that reads the serial port, and the same thing happens, it remains reading the same (first) data all the time. And I thing something like the enable Ack I'm missing. How can I do this enable Ack from my java code using rxtx? Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080807/e0a0f9a1/attachment-0024.html From ajmas at sympatico.ca Thu Aug 7 18:26:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 7 Aug 2008 20:26:41 -0400 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: <4BF42297-81E2-4BB8-A89F-1D43588379AE@sympatico.ca> On 6-Aug-08, at 19:40 , Bruce Boyes wrote: >> Unless I have missed the documentation for RXTX? I javadocced the >> RXTX >> source but information (to me) is minimal. >> Somewhere I got the impression that the Sun Comm API docs is, or was, >> compatible with RXTX, what is the best docs to use in conjuntion >> with RXTX >> and where may the be available? > > Yeah, this is one of my concerns/beefs. There is little documentation > for RXTX and it isn't just the same as javaxcomm. > > I would be willing to help out writing docs for RXTX! Yes really... > esp if we can fix the Bluetooth issues. If you want to contribute documentation then the best place to do that is the wiki. If there is anything missing or that could be improved on then please do so. If there are any points that you would like to see improved, for which you don't have the knowledge then ask on the mailing list for a volunteer. Andre From florianmanschwetus at gmx.de Fri Aug 8 03:04:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Fri, 08 Aug 2008 11:04:14 +0200 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Message-ID: <489C0C0E.2020401@gmx.de> Agustin Mu?oz schrieb: > Hi, I'm still learning about serial communication and I have some > doubts. I've got this question about how to do the following thing in rxtx. > I have this hardware that connect to a PC using a serial port. These > hardware receives data from a telephone line, proccess it, and then send > it forward to the serial port. I've used a program named wincomm that > shows what information is send it through the serial port and I have the > nex behaviour: > > The hardware has a buffer where all data is stored, that cannot be sent > it through the seria port. > The program reads the first data send it by the hardware, and keep > reading the same data always. > There is a button in the application that says enable Ack, and when I > click, then the hardware start to send all the stored information, and > all the information is shown. > > I write a class, using rxtx that reads the serial port, and the same > thing happens, it remains reading the same (first) data all the time. > And I thing something like the enable Ack I'm missing. > How can I do this enable Ack from my java code using rxtx? Afaik, a look at man ascii reveals: Okt Dez Hex Char 006 6 06 ACK So, i hope this will do the job: send(6); florian > > Thanks in advance > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/5b4965f8/attachment-0024.bin From agusmunioz at gmail.com Fri Aug 8 16:31:00 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 19:31:00 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <489C0C0E.2020401@gmx.de> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> Message-ID: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Hi Florian, thanks for the answer. By send(6) you mean to get the port OutputStream and write a 6? I try that but it didn't work. Any suggestion? Thanks On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < florianmanschwetus at gmx.de> wrote: > Agustin Mu?oz schrieb: > > Hi, I'm still learning about serial communication and I have some doubts. >> I've got this question about how to do the following thing in rxtx. >> I have this hardware that connect to a PC using a serial port. These >> hardware receives data from a telephone line, proccess it, and then send it >> forward to the serial port. I've used a program named wincomm that shows >> what information is send it through the serial port and I have the nex >> behaviour: >> >> The hardware has a buffer where all data is stored, that cannot be sent >> it through the seria port. >> The program reads the first data send it by the hardware, and keep reading >> the same data always. >> There is a button in the application that says enable Ack, and when I >> click, then the hardware start to send all the stored information, and all >> the information is shown. >> >> I write a class, using rxtx that reads the serial port, and the same thing >> happens, it remains reading the same (first) data all the time. And I thing >> something like the enable Ack I'm missing. >> How can I do this enable Ack from my java code using rxtx? >> > Afaik, a look at man ascii reveals: > Okt Dez Hex Char > 006 6 06 ACK > So, i hope this will do the job: > send(6); > > florian > >> >> Thanks in advance >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/7f3fba42/attachment-0023.html From agusmunioz at gmail.com Fri Aug 8 18:39:27 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 21:39:27 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Message-ID: <988288430808081739x7f9e7889id82591d5a9e2b4f6@mail.gmail.com> Ok, Florian, it works!! my problem was that I've been sending, through the OutputStream, the bytes of 6 as a string: out.write("6".getBytes()); but then I realized that you can write an int on an OuptuStream, so I tried that and It works: out.write(6); Thank you for the guidance!! On Fri, Aug 8, 2008 at 7:31 PM, Agustin Mu?oz wrote: > Hi Florian, thanks for the answer. By send(6) you mean to get the port > OutputStream and write a 6? > > I try that but it didn't work. > > Any suggestion? > > Thanks > > > On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < > florianmanschwetus at gmx.de> wrote: > >> Agustin Mu?oz schrieb: >> >> Hi, I'm still learning about serial communication and I have some doubts. >>> I've got this question about how to do the following thing in rxtx. >>> I have this hardware that connect to a PC using a serial port. These >>> hardware receives data from a telephone line, proccess it, and then send it >>> forward to the serial port. I've used a program named wincomm that shows >>> what information is send it through the serial port and I have the nex >>> behaviour: >>> >>> The hardware has a buffer where all data is stored, that cannot be sent >>> it through the seria port. >>> The program reads the first data send it by the hardware, and keep >>> reading the same data always. >>> There is a button in the application that says enable Ack, and when I >>> click, then the hardware start to send all the stored information, and all >>> the information is shown. >>> >>> I write a class, using rxtx that reads the serial port, and the same >>> thing happens, it remains reading the same (first) data all the time. And I >>> thing something like the enable Ack I'm missing. >>> How can I do this enable Ack from my java code using rxtx? >>> >> Afaik, a look at man ascii reveals: >> Okt Dez Hex Char >> 006 6 06 ACK >> So, i hope this will do the job: >> send(6); >> >> florian >> >>> >>> Thanks in advance >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/b918ab3d/attachment-0023.html From florianmanschwetus at gmx.de Sat Aug 9 00:45:43 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Sat, 09 Aug 2008 08:45:43 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4899667C.6010706@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> Message-ID: <489D3D17.9090209@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >> Florian Manschwetus wrote: >>> Ok, sounds fine for the receiving problem. >>> But why i have to wait after each byte when sending a command squence? >>> (the for loop in send command) >> >> Hi Florian, >> I'd imagine you probably don't! You could send all bytes in one go and >> RXTX would send them. The problem is most probably the other end: >> perhaps it has a really small buffer, some non-standard UART, or a >> crazy timing issue. If you attach a terminal to your output and send >> all the bytes of a command in one go they should appear no problem. >> >> Regards, >> Michael Erskine. >> > correct with a terminal on the other end it works, my idea was that this > basic baud has some influence. Could some one explain what it is for? > > Florian To make it more clear, my problem is that i can't use: outputStream.write(byte[]); => Beamer doesn't understand the sequence. (mostly no answer when he answers then *001) when i use this construct instead: for (int i = 0; i < command.length; i++) { this.outputStream.write(command[i]); try { Thread.sleep(25); } catch (InterruptedException e) { // TODO Auto-generated catch block e.printStackTrace(); } } it works nearly reliable. So what could it be? This Basic Baud is what exactly? Florian -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080809/692304ee/attachment-0023.bin From tjarvi at qbang.org Sat Aug 9 16:37:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Aug 2008 16:37:19 -0600 (MDT) Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489D3D17.9090209@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> <489D3D17.9090209@gmx.de> Message-ID: On Sat, 9 Aug 2008, Florian Manschwetus wrote: > Florian Manschwetus schrieb: >> Michael Erskine schrieb: >>> Florian Manschwetus wrote: >>>> Ok, sounds fine for the receiving problem. >>>> But why i have to wait after each byte when sending a command squence? >>>> (the for loop in send command) >>> >>> Hi Florian, >>> I'd imagine you probably don't! You could send all bytes in one go and >>> RXTX would send them. The problem is most probably the other end: perhaps >>> it has a really small buffer, some non-standard UART, or a crazy timing >>> issue. If you attach a terminal to your output and send all the bytes of a >>> command in one go they should appear no problem. >>> >>> Regards, >>> Michael Erskine. >>> >> correct with a terminal on the other end it works, my idea was that this >> basic baud has some influence. Could some one explain what it is for? >> >> Florian > To make it more clear, > my problem is that i can't use: > outputStream.write(byte[]); > => Beamer doesn't understand the sequence. (mostly no answer when he answers > then *001) > > when i use this construct instead: > > for (int i = 0; i < command.length; i++) { > this.outputStream.write(command[i]); > try { > Thread.sleep(25); > } catch (InterruptedException e) { > // TODO Auto-generated catch block > e.printStackTrace(); > } > } > > it works nearly reliable. > > So what could it be? This Basic Baud is what exactly? > I suspect you are using the 'moon protocol' and don't know it. RXTX enables this by default. The buffer on the other end is first in first out while reading. If the buffer is full, the bits are hand carried to the moon and burried. Then if the other side reads a couple bytes, two more bytes go into the buffer followed by more moon protocol. The resulting array of bytes the other side reads may appear to be scrambled until you go to the moon, get the bits and insert them in the right place. Flow control can prevent the default moon protocol and throttles the communiation by almost writing a byte at a time as need be. Hardware flow control is preferable but software flow control should also work. Read and write can appear to hang if the other side is not connected. This is why we don't enable them all the time. If you can't use flow control, you have to take care with the moon protocol and give the other side time to read. That is what your slower version of write is doing. -- Trent Jarvi tjarvi at qbang.org From rxtx at allenjb.me.uk Mon Aug 11 08:06:36 2008 From: rxtx at allenjb.me.uk (AllenJB) Date: Mon, 11 Aug 2008 15:06:36 +0100 Subject: [Rxtx] Disabling EV_RXFLAG Message-ID: <48A0476C.2090800@allenjb.me.uk> Hi all, I'm working with a device which does not use an EvtChar and need to disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an event mask of FD 01 00 00. The reference software I have uses FB 00 00 00. With the rxtx mask I get framing errors which I believe are caused when the EvtChar is received. Is there currently a way with rxtx (I've using rxtx from Java) to disable EV_RXFLAG? If not from Java, where would I start if I wanted to turn the EV_RXFLAG option off in the C code? I've had a grep of the rxtx source code, but I can't see where EV_RXFLAG is being set. Thanks in advance, AllenJB From tjarvi at qbang.org Mon Aug 11 14:17:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Aug 2008 14:17:27 -0600 (MDT) Subject: [Rxtx] Disabling EV_RXFLAG In-Reply-To: <48A0476C.2090800@allenjb.me.uk> References: <48A0476C.2090800@allenjb.me.uk> Message-ID: On Mon, 11 Aug 2008, AllenJB wrote: > Hi all, > > I'm working with a device which does not use an EvtChar and need to > disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an > event mask of FD 01 00 00. The reference software I have uses FB 00 00 > 00. With the rxtx mask I get framing errors which I believe are caused > when the EvtChar is received. > > Is there currently a way with rxtx (I've using rxtx from Java) to > disable EV_RXFLAG? > > If not from Java, where would I start if I wanted to turn the EV_RXFLAG > option off in the C code? I've had a grep of the rxtx source code, but I > can't see where EV_RXFLAG is being set. > > Thanks in advance, > > AllenJB Hi Allen, I'd look at termios.c::tcsetattr() and termios.c::FillDCB() -- Trent Jarvi tjarvi at qbang.org From superdadusa at gmail.com Tue Aug 12 13:57:32 2008 From: superdadusa at gmail.com (John Choi) Date: Tue, 12 Aug 2008 13:57:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. Message-ID: Hi all, Just let you all know I just start to learn Java. I have download the serial comm package and the source code from open source communities.. I was able to verify with the given message string via serial monitor. when the given message string sends to the serial port then the character return added to the end of string by default if I use "Hello World" however if I changed to something else other than "Hello, World" there is no character return add to the end of string. I thing the library download from rxtx.org has implemented for the special strings. I can do like "login\n" in the string message to make character return but I don't want to add this individual custom character for each command return in every static message string I send, Can any who have done this might help me? Basically, something like this,, Write and add function to the program write a command, Reads the respond from a serial device.. Function handles multiple messages, Write: "com open" Read: Welcome to my world" expected Write: "admin" Read: Password?, expected Write: "admin" Read: you are successfully login terminal, expected. And I need to add a separate function handler handles a character return add to the each command above. If anyone can help this I can do the reset? Thank you in advance, John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0019.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SerialIO.java Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0019.pl From Steffen.DETTMER at ingenico.com Wed Aug 13 02:16:38 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 13 Aug 2008 10:16:38 +0200 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: References: Message-ID: <20080813081638.GA25412@elberon.bln.de.ingenico.com> * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > I can do like "login\n" in the string message to make character > return but I don't want to add this individual custom character > for each command return in every static message string I send, and why not?! > Can any who have done this might help me? what's about with writing a small wrapper function adding the carriage return? However, this would be slow, because either you call write two times (very bad) or the string needs to be copied, \n appended and written (since you are using Java Performance probably isn't so critical). Personally I would write `"login\n"' and `username + "\n"' etc., because since it is part of the command it should be part of the command definition string. > Basically, something like this,, Write and add function to the program write > a command, Reads the respond from a serial device.. correctly reading a `line' is more difficult. If you cannot make assumptions about timeouts and/or you need to have low delay, you need to read byte wise. If you need to save CPU resources you might need to add some buffering layer that you can read byte-wise but that is reading blockwise with some small timeout (lets say for serial lines something around byte transmission time times three or so). > /* > * To change this template, choose Tools | Templates > * and open the template in the editor. > */ :) > package joliba; > > /** > * > * @author root > */ :) > // derived from SUN's examples in the javax.comm package > import java.io.*; > import java.util.*; > //import javax.comm.*; // for SUN's serial/parallel port libraries > import gnu.io.*; // for rxtxSerial library > > public class SerialIO implements Runnable, SerialPortEventListener { > static CommPortIdentifier portId; > static CommPortIdentifier saveportId; > static Enumeration portList; > InputStream inputStream; > SerialPort serialPort; > Thread readThread; You need a thread for your synchronous RPC-style protocol? > static String messageString = "Hello, world!"; > static OutputStream outputStream; > static boolean outputBufferEmptyFlag = false; > > public static void main(String[] args) { > boolean portFound = false; > String defaultPort; > > // determine the name of the serial port on several operating systems > String osname = System.getProperty("os.name","").toLowerCase(); > if ( osname.startsWith("windows") ) { > // windows > defaultPort = "COM1"; > } else if (osname.startsWith("linux")) { > // linux > defaultPort = "/dev/ttyS0"; > } else if ( osname.startsWith("mac") ) { > // mac > defaultPort = "????"; > } else { > System.out.println("Sorry, your operating system is not supported"); > return; > } Is such a construction recommended? Isn't there some abstraction (like COM1 working on any platform)? [...] > try { > // activate the OUTPUT_BUFFER_EMPTY notifier > serialPort.notifyOnOutputEmpty(true); > } catch (Exception e) { > System.out.println("Error setting event notification"); > System.out.println(e.toString()); > System.exit(-1); > } I doubt that -1 is defined, probably some 127 or so would be the result, maybe better simply `throw e'? > public void writetoport() { > System.out.println("Writing \""+messageString+"\" to "+serialPort.getName()); > try { > // write string to serial port > outputStream.write(messageString.getBytes()); > } catch (IOException e) {} > } maybe something like /** * Writes the given output string and an additional carriage * return to the current outputStream. */ public void writeStringToPort( /** The output string (without CR). */ String output ) throws IOException { String outputLine = output + "\n"; outputStream.write(outputLine.getBytes()); } ? > > public SerialIO() { > // initalize serial port > try { > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > } catch (PortInUseException e) {} if the port is in use, you continue? Wonder that this works in Java, I would assume serialPort beeing uninitialized which AFAIK is an error in Java. > try { > inputStream = serialPort.getInputStream(); > } catch (IOException e) {} > > try { > serialPort.addEventListener(this); > } catch (TooManyListenersException e) {} > > // activate the DATA_AVAILABLE notifier > serialPort.notifyOnDataAvailable(true); > > try { > // set port parameters > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > } catch (UnsupportedCommOperationException e) {} > > // start the read thread > readThread = new Thread(this); > readThread.start(); > > } I think in all those exception cases you can abort, because it is unlikely that ignoring those errors allow a successful continuation, so in this case maybe it would be better to add a throw clause to the method. > public void run() { > // first thing in the thread, we initialize the write operation > initwritetoport(); > try { > while (true) { > // write string to port, the serialEvent will read it > writetoport(); > Thread.sleep(1000); > } > } catch (InterruptedException e) {} > } Does this make sense? Your `SimpleReadApp' writes one and the same string each second? > public void serialEvent(SerialPortEvent event) { > switch (event.getEventType()) { > case SerialPortEvent.BI: > case SerialPortEvent.OE: > case SerialPortEvent.FE: > case SerialPortEvent.PE: > case SerialPortEvent.CD: > case SerialPortEvent.CTS: > case SerialPortEvent.DSR: > case SerialPortEvent.RI: > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > break; > case SerialPortEvent.DATA_AVAILABLE: > // we get here if data has been received > byte[] readBuffer = new byte[20]; > try { > // read data > while (inputStream.available() > 0) { > int numBytes = inputStream.read(readBuffer); > } > // print data > String result = new String(readBuffer); > System.out.println("Read: "+result); > } catch (IOException e) {} I doubt that this is correct. I would assume you will get a 20 bytes result always, if more bytes would be available they would be printed in a second line but if less bytes are read I'd assume that the buffer/result contains zero bytes from implicite readBuffer contents initialisation (zero is no string terminator in Java AFAIK). > break; > } > } > } oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From florianmanschwetus at gmx.de Wed Aug 13 06:09:31 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 13 Aug 2008 14:09:31 +0200 Subject: [Rxtx] someone has seen such errors? Message-ID: <48A2CEFB.90007@gmx.de> I mean my communication mostly works, but it is far from perfect could this be the reason? Florian Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/949b9947/attachment-0019.bin From superdadusa at gmail.com Wed Aug 13 08:40:32 2008 From: superdadusa at gmail.com (John Choi) Date: Wed, 13 Aug 2008 08:40:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: <20080813081638.GA25412@elberon.bln.de.ingenico.com> References: <20080813081638.GA25412@elberon.bln.de.ingenico.com> Message-ID: Thank you so much Steffen and I will try that suggestion. John On 8/13/08, Steffen DETTMER wrote: > > * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > > I can do like "login\n" in the string message to make character > > return but I don't want to add this individual custom character > > for each command return in every static message string I send, > > and why not?! > > > Can any who have done this might help me? > > what's about with writing a small wrapper function adding the > carriage return? > However, this would be slow, because either you call write two > times (very bad) or the string needs to be copied, \n appended > and written (since you are using Java Performance probably isn't > so critical). > > Personally I would write `"login\n"' and `username + "\n"' etc., > because since it is part of the command it should be part of the > command definition string. > > > Basically, something like this,, Write and add function to the program > write > > a command, Reads the respond from a serial device.. > > correctly reading a `line' is more difficult. If you cannot make > assumptions about timeouts and/or you need to have low delay, you > need to read byte wise. If you need to save CPU resources you > might need to add some buffering layer that you can read > byte-wise but that is reading blockwise with some small timeout > (lets say for serial lines something around byte transmission > time times three or so). > > > /* > > * To change this template, choose Tools | Templates > > * and open the template in the editor. > > */ > > :) > > > package joliba; > > > > /** > > * > > * @author root > > */ > > :) > > > // derived from SUN's examples in the javax.comm package > > import java.io.*; > > import java.util.*; > > //import javax.comm.*; // for SUN's serial/parallel port libraries > > import gnu.io.*; // for rxtxSerial library > > > > public class SerialIO implements Runnable, SerialPortEventListener { > > static CommPortIdentifier portId; > > static CommPortIdentifier saveportId; > > static Enumeration portList; > > InputStream inputStream; > > SerialPort serialPort; > > Thread readThread; > > You need a thread for your synchronous RPC-style protocol? > > > static String messageString = "Hello, world!"; > > static OutputStream outputStream; > > static boolean outputBufferEmptyFlag = false; > > > > public static void main(String[] args) { > > boolean portFound = false; > > String defaultPort; > > > > // determine the name of the serial port on several operating > systems > > String osname = System.getProperty("os.name","").toLowerCase(); > > if ( osname.startsWith("windows") ) { > > // windows > > defaultPort = "COM1"; > > } else if (osname.startsWith("linux")) { > > // linux > > defaultPort = "/dev/ttyS0"; > > } else if ( osname.startsWith("mac") ) { > > // mac > > defaultPort = "????"; > > } else { > > System.out.println("Sorry, your operating system is not > supported"); > > return; > > } > > Is such a construction recommended? Isn't there some abstraction > (like COM1 working on any platform)? > > [...] > > try { > > // activate the OUTPUT_BUFFER_EMPTY notifier > > serialPort.notifyOnOutputEmpty(true); > > } catch (Exception e) { > > System.out.println("Error setting event notification"); > > System.out.println(e.toString()); > > System.exit(-1); > > } > > I doubt that -1 is defined, probably some 127 or so would be the > result, maybe better simply `throw e'? > > > public void writetoport() { > > System.out.println("Writing \""+messageString+"\" to > "+serialPort.getName()); > > try { > > // write string to serial port > > outputStream.write(messageString.getBytes()); > > } catch (IOException e) {} > > } > > maybe something like > > /** > * Writes the given output string and an additional carriage > * return to the current outputStream. > */ > public void > writeStringToPort( > /** The output string (without CR). */ > String output > ) throws IOException > { > String outputLine = output + "\n"; > outputStream.write(outputLine.getBytes()); > } > > ? > > > > > public SerialIO() { > > // initalize serial port > > try { > > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > > } catch (PortInUseException e) {} > > if the port is in use, you continue? Wonder that this works in > Java, I would assume serialPort beeing uninitialized which AFAIK > is an error in Java. > > > try { > > inputStream = serialPort.getInputStream(); > > } catch (IOException e) {} > > > > try { > > serialPort.addEventListener(this); > > } catch (TooManyListenersException e) {} > > > > // activate the DATA_AVAILABLE notifier > > serialPort.notifyOnDataAvailable(true); > > > > try { > > // set port parameters > > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > } catch (UnsupportedCommOperationException e) {} > > > > // start the read thread > > readThread = new Thread(this); > > readThread.start(); > > > > } > > I think in all those exception cases you can abort, because it is > unlikely that ignoring those errors allow a successful > continuation, so in this case maybe it would be better to add a > throw clause to the method. > > > public void run() { > > // first thing in the thread, we initialize the write operation > > initwritetoport(); > > try { > > while (true) { > > // write string to port, the serialEvent will read it > > writetoport(); > > Thread.sleep(1000); > > } > > } catch (InterruptedException e) {} > > } > > Does this make sense? Your `SimpleReadApp' writes one and the > same string each second? > > > public void serialEvent(SerialPortEvent event) { > > switch (event.getEventType()) { > > case SerialPortEvent.BI: > > case SerialPortEvent.OE: > > case SerialPortEvent.FE: > > case SerialPortEvent.PE: > > case SerialPortEvent.CD: > > case SerialPortEvent.CTS: > > case SerialPortEvent.DSR: > > case SerialPortEvent.RI: > > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > > break; > > case SerialPortEvent.DATA_AVAILABLE: > > // we get here if data has been received > > byte[] readBuffer = new byte[20]; > > try { > > // read data > > while (inputStream.available() > 0) { > > int numBytes = inputStream.read(readBuffer); > > } > > // print data > > String result = new String(readBuffer); > > System.out.println("Read: "+result); > > } catch (IOException e) {} > > I doubt that this is correct. I would assume you will get a 20 > bytes result always, if more bytes would be available they would > be printed in a second line but if less bytes are read I'd assume > that the buffer/result contains zero bytes from implicite > readBuffer contents initialisation (zero is no string terminator > in Java AFAIK). > > > break; > > } > > } > > } > > oki, > > Steffen > > About Ingenico Throughout the world businesses rely on Ingenico for secure > and expedient electronic transaction acceptance. Ingenico products leverage > proven technology, established standards and unparalleled ergonomics to > provide optimal reliability, versatility and usability. This comprehensive > range of products is complemented by a global array of services and > partnerships, enabling businesses in a number of vertical sectors to accept > transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged > information. If you are not the addressee or authorized to receive this for > the addressee, you must not use, copy, disclose or take any action based on > this message or any information herein. If you have received this message in > error, please advise the sender immediately by reply e-mail and delete this > message. Thank you for your cooperation. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/73c4135c/attachment-0018.html From ajmas at sympatico.ca Sat Aug 16 07:15:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 09:15:41 -0400 Subject: [Rxtx] someone has seen such errors? In-Reply-To: <48A2CEFB.90007@gmx.de> References: <48A2CEFB.90007@gmx.de> Message-ID: <43B5E8DA-1D93-4D90-809B-AAF35FF724C5@sympatico.ca> On 13-Aug-08, at 08:09 , Florian Manschwetus wrote: > I mean my communication mostly works, but it is far from perfect > could this be the reason? > > Florian > > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control Judging by the error messages this looks related to the driver you are using. Do a search for the following string with you favourite search engine, it should turn up a few hits: ftdi_set_termios FAILED to set databits/stopbits/parity Andre From ajmas at sympatico.ca Sat Aug 16 19:12:04 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 21:12:04 -0400 Subject: [Rxtx] Using SerialPortEvent? Message-ID: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Hi, Could someone tell me how I should be using the SerialPortEvent? Am I meant to be waiting for data and then simply reading from the inputstream? If this is the case why no just block on an inputstream read? Andr? From tjarvi at qbang.org Sat Aug 16 19:41:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 16 Aug 2008 19:41:13 -0600 (MDT) Subject: [Rxtx] Using SerialPortEvent? In-Reply-To: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> References: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Message-ID: On Sat, 16 Aug 2008, Andre-John Mas wrote: > Hi, > > Could someone tell me how I should be using the SerialPortEvent? Am I > meant to be waiting for data and then simply reading from the > inputstream? If this is the case why no just block on an inputstream > read? > Polling for data is fine also. It really depends upon what you are trying to do. For instance, if you require x bytes before reading, you can start polling after data is available. If you read on the same thread as your GUI and are waiting for data in a read, the results may be less than desirable. Java programming is 'usually' event driven rather than polling based. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sat Aug 16 20:10:39 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 22:10:39 -0400 Subject: [Rxtx] Using SerialPortEvent? In-Reply-To: References: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Message-ID: <3E495D4C-BB28-4845-A6AB-984C9A826BDF@sympatico.ca> On 16-Aug-08, at 21:41 , Trent Jarvi wrote: > On Sat, 16 Aug 2008, Andre-John Mas wrote: > >> Hi, >> >> Could someone tell me how I should be using the SerialPortEvent? Am I >> meant to be waiting for data and then simply reading from the >> inputstream? If this is the case why no just block on an inputstream >> read? >> > > Polling for data is fine also. It really depends upon what you are > trying to do. For instance, if you require x bytes before reading, > you can start polling after data is available. If you read on the > same thread as your GUI and are waiting for data in a read, the > results may be less than desirable. > > Java programming is 'usually' event driven rather than polling based. Sounds good. I thought I would use this opportunity to provide a event based version of the TwoWaySerialComm example. Could you just validate it before I add it to the Wiki: package ajmas74.experimental; import gnu.io.CommPort; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; import gnu.io.SerialPortEvent; import gnu.io.SerialPortEventListener; import java.io.IOException; import java.io.InputStream; import java.io.OutputStream; /** * This version of the TwoWaySerialComm example makes use of the * SerialPortEventListener to avoid polling. * * @author ajmas * */ public class TwoWaySerialComm { public TwoWaySerialComm() { super(); } void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { CommPort commPort = portIdentifier.open(this.getClass().getName(),2000); if ( commPort instanceof SerialPort ) { SerialPort serialPort = (SerialPort) commPort; serialPort .setSerialPortParams (57600 ,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); (new Thread(new SerialWriter(out))).start(); serialPort.addEventListener(new SerialReader(in)); } else { System.out.println("Error: Only serial ports are handled by this example."); } } } /** * Handles the input coming from the serial port. A new line character * is treated as the end of a block in this example. */ public static class SerialReader implements SerialPortEventListener { private InputStream in; private byte[] buffer = new byte[1024]; public SerialReader ( InputStream in ) { this.in = in; } public void serialEvent(SerialPortEvent arg0) { int data; try { int len = 0; while ( ( data = in.read()) > -1 ) { if ( data != '\n' ) { break; } buffer[len++] = (byte) data; } System.out.print(new String(buffer,0,len)); } catch ( IOException e ) { e.printStackTrace(); System.exit(-1); } } } /** */ public static class SerialWriter implements Runnable { OutputStream out; public SerialWriter ( OutputStream out ) { this.out = out; } public void run () { try { int c = 0; while ( ( c = System.in.read()) > -1 ) { this.out.write(c); } } catch ( IOException e ) { e.printStackTrace(); System.exit(-1); } } } public static void main ( String[] args ) { try { (new TwoWaySerialComm()).connect("COM3"); } catch ( Exception e ) { e.printStackTrace(); } } } From lfarkas at lfarkas.org Tue Aug 19 07:32:59 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Tue, 19 Aug 2008 15:32:59 +0200 Subject: [Rxtx] JNI or CNI Message-ID: <48AACB8B.9060606@lfarkas.org> hi, what is the current recommended way to rxtx on linux JNI or it's better to use CNI? is the CNI version fully functional and the same level as the JNI? i currently try to make a rhel/centos/fedora rpm for rxtx but has many problems with the standard dir structure. yours. -- Levente "Si vis pacem para bellum!" From lfarkas at lfarkas.org Tue Aug 19 08:47:34 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Tue, 19 Aug 2008 16:47:34 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel Message-ID: <48AADD06.7040809@lfarkas.org> hi, newer or not so newer linux kernel do not contain the UTS_RELEASE so the current rxtx is not compile on the latest kernels. even if it's commented out in the cvs configure there are other places. i attcahed a patch which fix it (or at least doesn't cause error at non-debug build). ps. is there any plan to the new 2.1-8 release in the near future? there are many changes (at least the license change in all file and in this case create a diff is very difficult)? the latest release more then 2 years old:-( -- Levente "Si vis pacem para bellum!" -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-2.1-uts.patch Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080819/ab5d38ac/attachment-0012.pl From ajmas at sympatico.ca Tue Aug 19 16:21:53 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 19 Aug 2008 18:21:53 -0400 Subject: [Rxtx] Event based example Message-ID: <24735BFB-B088-4B84-8173-FE98DF63B12F@sympatico.ca> Hi, I have just posted an example of using SerialPortEventListener in the Wiki: http://rxtx.qbang.org/wiki/index.php/Event_Based_Two_Way_Communication If you see any issues please could you let me know, or makes the changes. Andre From Martin.Oberhuber at windriver.com Fri Aug 22 04:02:24 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 22 Aug 2008 12:02:24 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <48AADD06.7040809@lfarkas.org> References: <48AADD06.7040809@lfarkas.org> Message-ID: <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> Farkas, there are indeed efforts to get a new RXTX release out the door. Your experience as a package maintainer would likely be helpful during these efforts, since I'd think it makes sense to keep the patches minimal that you must make to have the source compile in your environment. What are the things that you find problematic, apart from the UTS thing that you have mentioned before? What is the timing that you have in mind for your package? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Farkas Levente > Sent: Tuesday, August 19, 2008 4:48 PM > To: rxtx at qbang.org > Subject: [Rxtx] UTS_RELEASE not defined in newer kernel > > hi, > newer or not so newer linux kernel do not contain the > UTS_RELEASE so the > current rxtx is not compile on the latest kernels. even if it's > commented out in the cvs configure there are other places. > i attcahed a patch which fix it (or at least doesn't cause error at > non-debug build). > > ps. is there any plan to the new 2.1-8 release in the near > future? there > are many changes (at least the license change in all file and in this > case create a diff is very difficult)? the latest release more then 2 > years old:-( > > -- > Levente "Si vis pacem para bellum!" > From lfarkas at lfarkas.org Fri Aug 22 04:36:26 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Fri, 22 Aug 2008 12:36:26 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> References: <48AADD06.7040809@lfarkas.org> <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> Message-ID: <48AE96AA.6090505@lfarkas.org> hi, the packages already build for fedora-9 and centos-5 and here: http://www.lfarkas.org/linux/packages/ what i've to patch, the UTS, the configure script, but it's already fixed in the cvs (in another way) and the loadlibrary. the reasons for last one can be found here: https://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_files_that_use_JNI after we test it i'd like to add these packages to fedora and epel main repository (that's why it's be useful a new release after 2 years:-) imho versions are cheap and why not just release 2.1-8? the real code changes are minimal and if something critical bug found still can release 2.1-9:-) ps. and would be better to use simple number for version like 2.1-7 rather then 2.1-7v2. Oberhuber, Martin wrote: > Farkas, > > there are indeed efforts to get a new RXTX release out the > door. Your experience as a package maintainer would likely > be helpful during these efforts, since I'd think it makes > sense to keep the patches minimal that you must make to > have the source compile in your environment. > > What are the things that you find problematic, apart from > the UTS thing that you have mentioned before? > > What is the timing that you have in mind for your package? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >> On Behalf Of Farkas Levente >> Sent: Tuesday, August 19, 2008 4:48 PM >> To: rxtx at qbang.org >> Subject: [Rxtx] UTS_RELEASE not defined in newer kernel >> >> hi, >> newer or not so newer linux kernel do not contain the >> UTS_RELEASE so the >> current rxtx is not compile on the latest kernels. even if it's >> commented out in the cvs configure there are other places. >> i attcahed a patch which fix it (or at least doesn't cause error at >> non-debug build). >> >> ps. is there any plan to the new 2.1-8 release in the near >> future? there >> are many changes (at least the license change in all file and in this >> case create a diff is very difficult)? the latest release more then 2 >> years old:-( >> >> -- >> Levente "Si vis pacem para bellum!" >> -- Levente "Si vis pacem para bellum!" From tjarvi at qbang.org Fri Aug 22 18:50:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Aug 2008 18:50:32 -0600 (MDT) Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <48AE96AA.6090505@lfarkas.org> References: <48AADD06.7040809@lfarkas.org> <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> <48AE96AA.6090505@lfarkas.org> Message-ID: Hi Farkas, The v2 was simply the second build - no code changes. We are comming out with a new release shortly. I would encourage working with distros as you are. The building of rxtx turns out to be a bottle neck in quick releases. We do want stable releases that work for a year or more but I would have no problems with quicker cycles on developing work. I would have no problem working with someone that did builds that receive less testing more often but they do have to come out for multiple platforms from this end. Thanks for the links. On Fri, 22 Aug 2008, Farkas Levente wrote: > hi, > the packages already build for fedora-9 and centos-5 and here: > http://www.lfarkas.org/linux/packages/ > what i've to patch, the UTS, the configure script, but it's already > fixed in the cvs (in another way) and the loadlibrary. the reasons for > last one can be found here: > https://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_files_that_use_JNI > after we test it i'd like to add these packages to fedora and epel main > repository (that's why it's be useful a new release after 2 years:-) > imho versions are cheap and why not just release 2.1-8? the real code > changes are minimal and if something critical bug found still can > release 2.1-9:-) > > ps. and would be better to use simple number for version like 2.1-7 > rather then 2.1-7v2. > > Oberhuber, Martin wrote: >> Farkas, >> >> there are indeed efforts to get a new RXTX release out the >> door. Your experience as a package maintainer would likely >> be helpful during these efforts, since I'd think it makes >> sense to keep the patches minimal that you must make to >> have the source compile in your environment. >> >> What are the things that you find problematic, apart from >> the UTS thing that you have mentioned before? >> >> What is the timing that you have in mind for your package? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >>> On Behalf Of Farkas Levente >>> Sent: Tuesday, August 19, 2008 4:48 PM >>> To: rxtx at qbang.org >>> Subject: [Rxtx] UTS_RELEASE not defined in newer kernel >>> >>> hi, >>> newer or not so newer linux kernel do not contain the >>> UTS_RELEASE so the >>> current rxtx is not compile on the latest kernels. even if it's >>> commented out in the cvs configure there are other places. >>> i attcahed a patch which fix it (or at least doesn't cause error at >>> non-debug build). >>> >>> ps. is there any plan to the new 2.1-8 release in the near >>> future? there >>> are many changes (at least the license change in all file and in this >>> case create a diff is very difficult)? the latest release more then 2 >>> years old:-( >>> >>> -- >>> Levente "Si vis pacem para bellum!" >>> > > > From andy at triera.net Sat Aug 23 15:17:44 2008 From: andy at triera.net (Andy Rozman) Date: Sat, 23 Aug 2008 21:17:44 +0000 Subject: [Rxtx] port not identified on FreeBSD In-Reply-To: References: Message-ID: <48B07E78.2030306@triera.net> Hi ! I have one small problem... I have started using FreeBSD in last few days and I have come accross a problem with rxtx on FreeBSD. I am using usb-to-serial converter, which is identified under FreeBSD without problem as ucom0, and creates link under /dev called ttyU0, which is correct way to be done under FreeBSD (if device would be unidentified it would be called ugen0 - as usb generic). Problem is that I say to rxtx to get my all serial ports this one is not among them. Which names are permissable under linux-like implementations? Which will be accepted as serial ports? Andy From tjarvi at qbang.org Sat Aug 23 13:57:45 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 23 Aug 2008 13:57:45 -0600 (MDT) Subject: [Rxtx] port not identified on FreeBSD In-Reply-To: <48B07E78.2030306@triera.net> References: <48B07E78.2030306@triera.net> Message-ID: On Sat, 23 Aug 2008, Andy Rozman wrote: > Hi ! > > I have one small problem... I have started using FreeBSD in last few > days and I have come accross a problem with rxtx on FreeBSD. > > I am using usb-to-serial converter, which is identified under FreeBSD > without problem as ucom0, and creates link under /dev called > ttyU0, which is correct way to be done under FreeBSD (if device would be > unidentified it would be called ugen0 - as usb generic). Problem is that > I say to rxtx to get my all serial ports this one is not among them. > Which names are permissable under linux-like implementations? Which will > be accepted as serial ports? > > Andy > Thanks Andy! We will add ttyU* to FreeBSD. For now you can use properties to enable the port. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting#How_does_rxtx_detect_ports.3F__Can_I_override_it.3F The fix: diff -u -r1.16.2.59 RXTXCommDriver.java --- RXTXCommDriver.java 18 Nov 2007 22:32:41 -0000 1.16.2.59 +++ RXTXCommDriver.java 23 Aug 2008 19:55:25 -0000 @@ -644,6 +644,7 @@ { String[] Temp = { "ttyd", //general purpose serial ports + "ttyU", //general purpose USB serial ports "cuaa", //dialout serial ports "ttyA", //Specialix SI/XIO dialin ports "cuaA", //Specialix SI/XIO dialout ports -- Trent Jarvi tjarvi at qbang.org From rick_knight at rlknight.com Mon Aug 4 13:25:10 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Mon, 04 Aug 2008 12:25:10 -0700 Subject: [Rxtx] Sun's Comm API? Message-ID: <48975796.4010600@rlknight.com> I have an application that requires the javax compatible version of RXTX and Sun's comm api. I've been able to download and extract the version of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api anywhere. Can someone tell me where I can find it? Or maybe send me a copy? Also, when I try to build RXTX, configure and make complete successfully but make install failes with this error libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 I've never come accross this error before. How can I get past it? Thanks, Rick From bboyes at systronix.com Mon Aug 4 19:10:01 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:10:01 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48975796.4010600@rlknight.com> References: <48975796.4010600@rlknight.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/cb9c6167/attachment-0028.html From bboyes at systronix.com Mon Aug 4 19:12:37 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:12:37 -0600 Subject: [Rxtx] Towards an RXTX release - CSR BT/USB chipset In-Reply-To: <488FB7E7.8000802@gmail.com> References: <460801A4097E3D4CA04CC64EE648584806C56CF0@ism-mail03.corp.ad.wrs.com> <13557-75390@sneakemail.com> <20980-23424@sneakemail.com> <488FB7E7.8000802@gmail.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/52236088/attachment-0028.html From tjarvi at qbang.org Mon Aug 4 19:42:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 19:42:21 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: On Mon, 4 Aug 2008, Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: > I have an application that requires the javax compatible > version of RXTX > and Sun's comm api. I've been able to download and extract > the version > of RXTX that I need (2.0-7pre2) but I can't find Sun's camm > api > anywhere. Can someone tell me where I can find it? Or maybe > send me a > > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm port > support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have just > a ZIP with only the .class JAR file - no source or docs), has a readme > with these comments: > > This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release.? The 2.0.3 release itself is > no longer distributed.? comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project.? The RxTx project (http://www.rxtx.org ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org) was opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support.? Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins.? Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > ? > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > I hope that is helpful! > It would be nice to work with Sun to resolve those longstanding issues. But it may not be practical unless the process goes as fast and painless as the grandfathering of commapi did. Another option may be the old kaffe extensions that moved to gnu classpathx. These don't have the native libraries but should provide the 2.0 interface and the javax.comm.properties mechansim for SPI. http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Mon Aug 4 20:23:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Mon, 04 Aug 2008 20:23:57 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4897B9BD.5070809@ergotech.com> Has there been any work/would it be possible, to layer a javacomm look-alike on top of the GNU code? The goal is not to move the javax code forward, but to emulate the "legacy" javax packages for people who still need this. Jim Trent Jarvi wrote: > On Mon, 4 Aug 2008, Bruce Boyes wrote: > >> At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible >> version of RXTX >> and Sun's comm api. I've been able to download and extract >> the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm >> api >> anywhere. Can someone tell me where I can find it? Or maybe >> send me a >> >> >> javaxcomm has had a sort of on-again off-again history. The windoze >> version has been languishing for years (literally) but there are newer >> versions for other OS's. >> >> We try to keep links on one of our help pages current: >> http://www.practicalembeddedjava.com/tools/javatools_list.html >> which gets you to here: >> http://java.sun.com/products/javacomm/ >> where it says in fact they no longer even support Windows and Mac: >> "Implementations of the API are currently available for Solaris SPARC, >> Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so >> someone could support it. But I guess that's part of the reason RXTX >> exists! >> >> So one of Sun's own products, SunSPOT, has to use RXTX to get comm port >> support. >> >> The version we use is 2.0 from 11/15/1998. I have posted it on our >> website, which is within the terms of the license agreement contained >> therein (as I understand it). >> >> The last version of javaxcomm for Windows, 2.0.3, (for which I have just >> a ZIP with only the .class JAR file - no source or docs), has a readme >> with these comments: >> >> This distribution contains the comm.jar file original part >> of the COMMAPI 2.0.3 release. The 2.0.3 release itself is >> no longer distributed. comm.jar, which contains the comm >> API java class files (eg. Sun's binary implementation of the >> interface classes), is being made available, unsupported, >> with no obligation to fix bugs, at the request of the RXTX >> project. The RxTx project (http://www.rxtx.org ), uses the >> comm.jar class files, but provides their own native library >> components to provide support for other platforms. >> >> The 2.0.3 comm.jar is being provided in this way because >> as of COMMAPI 3.x, the java binary implementation forked and >> became incompatible with the RxTx project's native code. >> Due to the lack of a clear business case, and to resource >> constraints, no additional resources are being >> provided to provide an alternative engineering solution >> at the time of writing. >> >> RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: >> >> Ultimately the COMMAPI would be better served if a Java >> Community Process JSR (http://www.jcp.org) was opened and >> the COMMAPI was rearchitected to provide a more pluggable >> framework to improve cross-platform support. Such an >> architecture would embody a better defined and better >> documented SPI interface, including a way for comm. ports >> to be revealed to the client application through the API >> via platform-aware plugins. Similarly, native code used >> to access comm port in general could be handled more >> flexibly using a plugin model, whereby on any platform, >> multiple native modules could be in use simultaneously. >> >> Since there are now various ways serial ports can be implemented >> and accessed, modular comm. port JNI native libraries would be >> of benefit insofar as removing the burden of over-generalization >> from any single native component, or inversely, by relieving the >> implicit constraint that comm. drivers be accessed only via a >> monolithic mechanism, such as the UNIX vnode interface. >> >> paul.klissner at sun.com >> 6/10/06 >> >> I hope that is helpful! >> > > It would be nice to work with Sun to resolve those longstanding issues. > But it may not be practical unless the process goes as fast and painless > as the grandfathering of commapi did. > > Another option may be the old kaffe extensions that moved to gnu > classpathx. These don't have the native libraries but should provide > the 2.0 interface and the javax.comm.properties mechansim for SPI. > > http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Mon Aug 4 21:09:15 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 21:09:15 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? Message-ID: Hi Jim, I will not step into the javax.comm namespace without Sun's explicite permission. I fully understand the pain point you are trying to address. In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm Linux) - which remains an integral part of rxtx. At the time it was a win for Sun and rxtx. The Sun commapi license is/was fairly clear that rxtx should not step into that namespace. It made sense as Sun was active in that space and rxtx may go into another namespace - it was an experiment in working with Sun. This may sound silly looking at something that happened almost 10 years ago. In a community of respect which Sun helped create, there is no question about what to do. I hope eventually Sun will step up and do a right thing too. I agree that this is hurting the API more than helping it. There are also questions about how to replace the API in the long term which includes HID support which isn't going well so far. Others that can't even look at Sun's javax.comm today and can look at Kaffe's contribution to classpathx can easily work around such restrictions. On Mon, 4 Aug 2008, Jim Redman wrote: > Has there been any work/would it be possible, to layer a javacomm > look-alike on top of the GNU code? > > The goal is not to move the javax code forward, but to emulate the > "legacy" javax packages for people who still need this. > > Jim > > Trent Jarvi wrote: >> >> It would be nice to work with Sun to resolve those longstanding issues. >> But it may not be practical unless the process goes as fast and painless >> as the grandfathering of commapi did. >> >> Another option may be the old kaffe extensions that moved to gnu >> classpathx. These don't have the native libraries but should provide >> the 2.0 interface and the javax.comm.properties mechansim for SPI. >> >> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From florianmanschwetus at gmx.de Tue Aug 5 05:04:46 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 13:04:46 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: References: <48971C1F.9020806@gmx.de> Message-ID: <489833CE.1040801@gmx.de> Just look at sendCommand in this method I have to place a Thread.sleep(20) after each byte send to get working. Even the event based receive doesn't work fine but this could be may stupidness. The specifikation document (it is on the last pages of the manual) for the beamer could be found on: http://www.optoma.co.uk/support.aspx Florian Manschwetus Trent Jarvi schrieb: > > Hi Florian > > Sorry for the top post in advance. I worry you may not see my answer > under all your code :) > > I have not received this email before. This is 500k of code which I > don't have time to read. I can spend about 5 min on each hobby email > and still get to work in the morning. I have a couple suggestions for > how to get an answer. > > First, cut out your comments and extra code so you can demonstrate the > question (I might even glance and see what is wrong then). Don't go for > a working final product. Isolate the problem using a simple program and > then ask with that as an example. If I did what you just did, I'd have > to post 3/4 of a million lines of code :) > > Second, join the rxtx mail-list and ask there. This will give you 100x > more eyes. I'll also read and try to follow. > > -- > taj > > > > On Mon, 4 Aug 2008, Florian Manschwetus wrote: > >> It could be that my university account is blocked by filters so >> resending from here. >> >> >> Topic is to control Optoma HD80 beamer using rs232 serial chat. >> This code is able to detect power state and switch the beamer on / off. >> connected is the beamer using a digitus usb 2.0 serial adapter with an >> FT232 USB-Serial adapter the systems architecture is amd64. >> >> Please take a look in the sendCommand routine i have to place theire >> those Thread.sleep to get it working. >> Now the question is this correct or is there a better way to get this >> working correctly? >> >> In the javadoc coming with the install i found this: >> setBaudBase >> >> public boolean setBaudBase(int BaudBase) >> throws UnsupportedCommOperationException, >> java.io.IOException >> >> Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 >> before using. >> >> could this explain the error? >> I attached my java source and the protocol description for the beamer >> (available on vendor website). >> >> thx, >> Florian Manschwetus >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: TestRS232.java Type: text/x-java Size: 9143 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0056.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0057.bin From michael.erskine at ketech.com Tue Aug 5 05:53:49 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Tue, 5 Aug 2008 12:53:49 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489833CE.1040801@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> > Just look at sendCommand in this method I have to place a > Thread.sleep(20) after each byte send to get working. Even the event > based receive doesn't work fine but this could be may stupidness. Hi Florian, Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. Regards, Michael Erskine. From florianmanschwetus at gmx.de Tue Aug 5 07:28:15 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:28:15 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> Message-ID: <4898556F.8000208@gmx.de> Michael Erskine schrieb: >> Just look at sendCommand in this method I have to place a >> Thread.sleep(20) after each byte send to get working. Even the event >> based receive doesn't work fine but this could be may stupidness. > > Hi Florian, > > Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. > > Regards, > Michael Erskine. > Ok, sounds fine for the receiving problem. But why i have to wait after each byte when sending a command squence? (the for loop in send command) Florian > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/284f350c/attachment-0027.bin From florianmanschwetus at gmx.de Tue Aug 5 07:44:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:44:14 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <4898592E.2020908@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >>> Just look at sendCommand in this method I have to place a >>> Thread.sleep(20) after each byte send to get working. Even the event >>> based receive doesn't work fine but this could be may stupidness. >> >> Hi Florian, >> >> Yes, naturally you'll have to wait for a response from the other end. >> Why not wait for notification from the event thread perhaps using a >> BlockingDeque rather than your LinkedList. Generally I >> try to decouple all input and output streams: in your case your >> application is operating synchronously like the "expect" program >> (http://expect.nist.gov/) so waits (or timeouts) will need to be >> factored in. >> >> Regards, >> Michael Erskine. >> > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) > > Florian Furthermore there is this basic baud with this confusing javadoc entry: public boolean setBaudBase(int BaudBase) throws UnsupportedCommOperationException, java.io.IOException Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 before using. maybe this could explain something Florian >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/006c7425/attachment-0027.bin From jredman at ergotech.com Tue Aug 5 09:13:36 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 05 Aug 2008 09:13:36 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: Message-ID: <48986E20.3060104@ergotech.com> Trent, So two issues: 1) Technically I'm still not sure how easy/practical a layer would be. The problems are always classes like listeners, and wrapping returns of gnu.io classes. I really see it as a "delegate" type of concept. Any thoughts or ideas of the practicality of this approach? The idea is not to modify RXTX. 2) Javax. The javax namespace does seem to be in widespread use outside of Sun (the same is true for the java namespace). The classpath extensions, or some other location, should be interested in a JavaComm implementation even if it does have dependencies on RXTX. Would you have any philosophical objection to an approach like that? Of course, I suspect it might be better if someone with that authority at Sun would admit that the javax namespace is already in the wild and that there is no problem with it being used within RXTX. Jim Trent Jarvi wrote: > Hi Jim, > > I will not step into the javax.comm namespace without Sun's explicite > permission. I fully understand the pain point you are trying to address. > > In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm > Linux) - which remains an integral part of rxtx. At the time it was a win for > Sun and rxtx. > > The Sun commapi license is/was fairly clear that rxtx should not step into that > namespace. It made sense as Sun was active in that space and rxtx may go into > another namespace - it was an experiment in working with Sun. > > This may sound silly looking at something that happened almost 10 years ago. > In a community of respect which Sun helped create, there is no question about > what to do. I hope eventually Sun will step up and do a right thing too. > > I agree that this is hurting the API more than helping it. There are also > questions about how to replace the API in the long term which includes HID > support which isn't going well so far. > > Others that can't even look at Sun's javax.comm today and can look at Kaffe's > contribution to classpathx can easily work around such restrictions. > > On Mon, 4 Aug 2008, Jim Redman wrote: > >> Has there been any work/would it be possible, to layer a javacomm >> look-alike on top of the GNU code? >> >> The goal is not to move the javax code forward, but to emulate the >> "legacy" javax packages for people who still need this. >> >> Jim >> >> Trent Jarvi wrote: >>> It would be nice to work with Sun to resolve those longstanding issues. >>> But it may not be practical unless the process goes as fast and painless >>> as the grandfathering of commapi did. >>> >>> Another option may be the old kaffe extensions that moved to gnu >>> classpathx. These don't have the native libraries but should provide >>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>> >>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From sandeep at genevasoftech.com Tue Aug 5 11:18:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Tue, 05 Aug 2008 22:48:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <48988B6C.5080409@genevasoftech.com> Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. *-- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/ad20f1cb/attachment-0027.html From Martin.Oberhuber at windriver.com Tue Aug 5 13:30:17 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Tue, 5 Aug 2008 21:30:17 +0200 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Sandeep, shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on Sol7 but I've successfully run it on Sol9 and Sol10. Or is your request really about a native 64bit variant? I'm afraid that then you're out of luck since I think that quite a bit of RXTX is not yet ready for 64 bit. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Sandeep Kumar K Sent: Tuesday, August 05, 2008 7:19 PM To: rxtx at qbang.org Subject: [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so for Solaris 9 Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. -- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/81b7f988/attachment-0027.html From tjarvi at qbang.org Tue Aug 5 22:38:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 22:38:34 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 5 Aug 2008, Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built > on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid that > then > you're out of luck since I think that quite a bit of RXTX is not yet > ready > for 64 bit. > While rxtx-2.1-7 probably has problems, The CVS code should be OK for 64 bit Solaris. If it isn't, let me know and I'll find which patch is missing. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Aug 5 23:13:00 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 23:13:00 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48986E20.3060104@ergotech.com> References: <48986E20.3060104@ergotech.com> Message-ID: On Tue, 5 Aug 2008, Jim Redman wrote: > Trent, > > So two issues: > > 1) Technically I'm still not sure how easy/practical a layer would be. The > problems are always classes like listeners, and wrapping returns of gnu.io > classes. I really see it as a "delegate" type of concept. Any thoughts or > ideas of the practicality of this approach? The idea is not to modify RXTX. I have not put too much thought into this. I assume you want what rxtx 2.0 provided to tie into javax.comm implementations. More classes could be added to rxtx 2.1-7 for SPI support. Maintaining rxtx-2.0 could also be handed to someone if they like. > > 2) Javax. The javax namespace does seem to be in widespread use outside of > Sun (the same is true for the java namespace). The classpath extensions, or > some other location, should be interested in a JavaComm implementation even > if it does have dependencies on RXTX. Would you have any philosophical > objection to an approach like that? > No problems. Classpathx would be a possible place to do it. I'd suggest thinking twice about what this involves in practical terms. You would be wanting to revive the 2.0 API while Sun is at 3.0 and grandfathering the JSR. This undermines the main reason (established api) for using the javax.comm namespace and does not leave such a project in a good position. The only win I see here is maintaining support for applications that can't migrate namespaces. Not that that isn't important. At some point it is going to be less work to just edit the bytecode :) Such a javax.comm effort would also be signing up new projects that decided to use the work up for concerns they probably will not understand or expect. That probably isn't a good path to facilitate for new projects at this time. We will put a good faith effort to work well with others but keep in mind the project has limited bandwidth for such efforts. > Of course, I suspect it might be better if someone with that authority at Sun > would admit that the javax namespace is already in the wild and that there is > no problem with it being used within RXTX. > > Jim > > Trent Jarvi wrote: >> Hi Jim, >> >> I will not step into the javax.comm namespace without Sun's explicite >> permission. I fully understand the pain point you are trying to address. >> >> In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java >> Comm Linux) - which remains an integral part of rxtx. At the time it was a >> win for Sun and rxtx. >> >> The Sun commapi license is/was fairly clear that rxtx should not step into >> that namespace. It made sense as Sun was active in that space and rxtx may >> go into another namespace - it was an experiment in working with Sun. >> >> This may sound silly looking at something that happened almost 10 years >> ago. In a community of respect which Sun helped create, there is no >> question about what to do. I hope eventually Sun will step up and do a >> right thing too. >> >> I agree that this is hurting the API more than helping it. There are also >> questions about how to replace the API in the long term which includes HID >> support which isn't going well so far. >> >> Others that can't even look at Sun's javax.comm today and can look at >> Kaffe's contribution to classpathx can easily work around such >> restrictions. >> >> On Mon, 4 Aug 2008, Jim Redman wrote: >> >>> Has there been any work/would it be possible, to layer a javacomm >>> look-alike on top of the GNU code? >>> >>> The goal is not to move the javax code forward, but to emulate the >>> "legacy" javax packages for people who still need this. >>> >>> Jim >>> >>> Trent Jarvi wrote: >>>> It would be nice to work with Sun to resolve those longstanding issues. >>>> But it may not be practical unless the process goes as fast and painless >>>> as the grandfathering of commapi did. >>>> >>>> Another option may be the old kaffe extensions that moved to gnu >>>> classpathx. These don't have the native libraries but should provide >>>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>>> >>>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From sandeep at genevasoftech.com Wed Aug 6 00:03:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Wed, 06 Aug 2008 11:33:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: <48993EB8.30107@genevasoftech.com> Thank you Mr. Martin for your suggestion. The native file which is given in rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am getting the following error . Any suggestions to solve this issue. I am using Solaris SPARC 64 bit machine. ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) thrown while loading gnu.io.RXTXCommDriver Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(Unknown Source) at java.lang.ClassLoader.loadLibrary(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) at com.ReadFromModem.main(ReadFromModem.java:84) * * *Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid > that then > you're out of luck since I think that quite a bit of RXTX is not yet ready > for 64 bit. > > Cheers, > -- > *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > ------------------------------------------------------------------------ > *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On > Behalf Of *Sandeep Kumar K > *Sent:* Tuesday, August 05, 2008 7:19 PM > *To:* rxtx at qbang.org > *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so > for Solaris 9 > > Hi, > > Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 > bit machine. The librxtxSerial.so given in website is for Solaris 8. > > *-- > > Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/1e920343/attachment-0027.html From tjarvi at qbang.org Wed Aug 6 00:21:42 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 00:21:42 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <48993EB8.30107@genevasoftech.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> <48993EB8.30107@genevasoftech.com> Message-ID: Hi Sandeep You may be out of luck unless you can compile the 2.1 src in CVS (requires gnu make and gcc). But you could try the ToyBox(R)(TM) which is a collection of WiLdLy untested cross compiled 2.1-7 binaries covering everything from the ibm z series to embeded arm/ppc. To give an idea how poorly these are tested, I don't even know if z series machines have a serial port. ftp://www.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Solaris They should at least match the binary types. Actually, I think if you use the rxtx jar from CVS with that file, it should 'work' as the fix for 64 bits was in java not the native code. You could just cd rxtx*/src; javac *.java then jar -cf RXTXcomm.jar `find -name \*.class` to create the hybrid which will complain about version information a bit. On Wed, 6 Aug 2008, Sandeep Kumar K wrote: > Thank you Mr. Martin for your suggestion. The native file which is given in > rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am > getting the following error . > Any suggestions to solve this issue. > I am using Solaris SPARC 64 bit machine. > > ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar > java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 > (Possible cause: architecture word > width mismatch) thrown while loading gnu.io.RXTXCommDriver > Exception in thread "main" java.lang.UnsatisfiedLinkError: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF > class: ELFCLASS64 (Possible cause: > architecture word width mismatch) > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(Unknown Source) > at java.lang.ClassLoader.loadLibrary(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > at com.ReadFromModem.main(ReadFromModem.java:84) > > * > * > > *Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > > > Oberhuber, Martin wrote: >> Sandeep, >> shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse >> variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on >> Sol7 but I've successfully run it on Sol9 and Sol10. >> Or is your request really about a native 64bit variant? I'm afraid that >> then >> you're out of luck since I think that quite a bit of RXTX is not yet ready >> for 64 bit. >> Cheers, >> -- >> *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> ------------------------------------------------------------------------ >> *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On >> Behalf Of *Sandeep Kumar K >> *Sent:* Tuesday, August 05, 2008 7:19 PM >> *To:* rxtx at qbang.org >> *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so >> for Solaris 9 >> >> Hi, >> >> Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 >> bit machine. The librxtxSerial.so given in website is for Solaris 8. >> >> *-- >> Thanks & Regards >> >> Sandeep Kumar K >> Sr. Software Engineer >> Geneva Software Technologies >> Whitefield, Bangalore >> Mob : 9880193454* >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> From michael.erskine at ketech.com Wed Aug 6 01:39:28 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 6 Aug 2008 08:39:28 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Florian Manschwetus wrote: > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) Hi Florian, I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. Regards, Michael Erskine. From florianmanschwetus at gmx.de Wed Aug 6 02:53:16 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 06 Aug 2008 10:53:16 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Message-ID: <4899667C.6010706@gmx.de> Michael Erskine schrieb: > Florian Manschwetus wrote: >> Ok, sounds fine for the receiving problem. >> But why i have to wait after each byte when sending a command squence? >> (the for loop in send command) > > Hi Florian, > I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. > > Regards, > Michael Erskine. > correct with a terminal on the other end it works, my idea was that this basic baud has some influence. Could some one explain what it is for? Florian > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/c2b4fa84/attachment-0027.bin From rick_knight at rlknight.com Wed Aug 6 13:01:07 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:01:07 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F4F3.3020707@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > I have an application (Readerware) that uses RXTX with Javax to access the serial port. This used to work fine under previous Linux' and Java, but something has changed, I assume with Java itself , that is causing the application to fail with a link error. The application is not able to find librxtxSerialParallel.so. RXTX supplies librxtxSerial.so and librxtxParallel.so, but not librxtxSerialParallel.so. Where can I get librxtxSerialParallel.so, or do I need it? Is something else causing the lib to not be found? Thanks, Rick Knight From rick_knight at rlknight.com Wed Aug 6 13:17:55 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:17:55 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F8E3.5060400@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Thanks for the reply. The developer of the app I'm trying to use (Readerware) has sent me a copy of the comm.api and I've copied the library (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar into the proper places. When I try to run the application, I get this error... Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: /usr/lib/libSolarisSerialParallel.so: /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not little-endian (Possible cause: endianness mismatch) Caught java.lang.UnsatisfiedLinkError: com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I while loading driver com.sun.comm.SolarisDriver Is there a way around this error? Thanks again, Rick Knight From jlar310 at gmail.com Wed Aug 6 13:37:42 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 14:37:42 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899F8E3.5060400@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > The developer of the app I'm trying to use (Readerware) has sent me a > copy of the comm.api and I've copied the library > (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar > into the proper places. When I try to run the application, I get this > error... > > Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: > /usr/lib/libSolarisSerialParallel.so: > /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not > little-endian (Possible cause: endianness mismatch) > Caught java.lang.UnsatisfiedLinkError: > com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I > > while loading driver com.sun.comm.SolarisDriver > > Is there a way around this error? What host OS are you running? From your original post it looks like 32 bit Linux. The libSolarisSerialParallel.so file is for Sun Solaris and will vary depending on the underlying hardware architecture as well. Sorry for the double post Rick, but I failed to send this to the list the first time... -- Jeff From rick_knight at rlknight.com Wed Aug 6 13:44:29 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:44:29 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: <4899FF1D.9030504@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > > >> The developer of the app I'm trying to use (Readerware) has sent me a >> copy of the comm.api and I've copied the library >> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >> into the proper places. When I try to run the application, I get this >> error... >> >> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >> /usr/lib/libSolarisSerialParallel.so: >> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >> little-endian (Possible cause: endianness mismatch) >> Caught java.lang.UnsatisfiedLinkError: >> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >> >> while loading driver com.sun.comm.SolarisDriver >> >> Is there a way around this error? >> > > What host OS are you running? From your original post it looks like 32 > bit Linux. > > The libSolarisSerialParallel.so file is for Sun Solaris and will vary > depending on the underlying hardware architecture as well. > > I'm running Kubuntu Linux (debian based). It's 32 bit. Rick Knight From jlar310 at gmail.com Wed Aug 6 15:33:23 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 16:33:23 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > I don't think Sun did binary libraries for Linux in the 2.0 version. Can someone with more historical experience than I confirm that? I recently tried to port a Comm API application from Solaris sparc to Linux x86 and likewise could not get my hands on the binary libraries. I eventually just re-wrote the code to use the gnu namespace packages and rxtx 2.1. What I don't understand is why your application vendor does not provide everything you need to run their software. FYI: I have librxtxParallel.so and librxtxSerial.so installed at JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is /usr/java/default which is actually a softlink to /usr/java/jre1.6.0_05. -- Jeff From defiantlew at yahoo.com.au Wed Aug 6 16:29:33 2008 From: defiantlew at yahoo.com.au (Lew L) Date: Thu, 7 Aug 2008 08:29:33 +1000 Subject: [Rxtx] Sun's Comm API Documentation References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> Message-ID: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> As a matter of interest is the Sun Comm API documentation available somewhere? I have tried the Sun site but it seems to have been removed. Unless I have missed the documentation for RXTX? I javadocced the RXTX source but information (to me) is minimal. Somewhere I got the impression that the Sun Comm API docs is, or was, compatible with RXTX, what is the best docs to use in conjuntion with RXTX and where may the be available? Cheers Lew From rick_knight at rlknight.com Wed Aug 6 17:18:33 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:18:33 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A3149.4050306@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff I'm not sure if I posted this here or not, but when I try to build RXTX from source I get this install error... make all-am make[1]: Entering directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' make[1]: Nothing to be done for `all-am'. make[1]: Leaving directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 Can you tell me how to get past this error and get RXTX built and installed? Thanks, Rick From bboyes at systronix.com Wed Aug 6 17:40:12 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Wed, 06 Aug 2008 17:40:12 -0600 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: At 16:29 08/06/2008, Lew L wrote: >As a matter of interest is the Sun Comm API documentation available >somewhere? I have tried the Sun site but it seems to have been removed. It's in the file we have posted, link in prev email (sorry, in a huge hurry right now). Javadocs definitely there. >Unless I have missed the documentation for RXTX? I javadocced the RXTX >source but information (to me) is minimal. >Somewhere I got the impression that the Sun Comm API docs is, or was, >compatible with RXTX, what is the best docs to use in conjuntion with RXTX >and where may the be available? Yeah, this is one of my concerns/beefs. There is little documentation for RXTX and it isn't just the same as javaxcomm. I would be willing to help out writing docs for RXTX! Yes really... esp if we can fix the Bluetooth issues. best regards Bruce >Cheers >Lew > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx ------- WWW.SYSTRONIX.COM ---------- Real embedded Java and much more +1-801-534-1017 Salt Lake City, USA From rick_knight at rlknight.com Wed Aug 6 17:54:08 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:54:08 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A39A0.2090309@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff, I would like for my vendor to switch to rxtx 2.1. It would make things much easier for me. I'm not sure why he's still using the javax compatible code. He's a small operation. Re-writing the code to use gnu namespace sounds like a major overhaul. Was it? Thanks, Rick From tjarvi at qbang.org Wed Aug 6 21:35:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:35:12 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: >> >>> Jeff wrote: >>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>>> >>>> >>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things > much easier for me. I'm not sure why he's still using the javax > compatible code. He's a small operation. Re-writing the code to use gnu > namespace sounds like a major overhaul. Was it? > Hi Jeff, The changes are fairly mechanical. Imports need to change and any explicite use of the namespace needs to change such as catching an exception. The following script was made for maintaining rxtx 2.0 but can apply to other needs. It is in the contrib dir with rxtx source. #!/bin/sh # Don't use! :) # # Sat, 03 May 2003 16:45:08 Modifications from J?rg Weule # Create a ed-cmd for the change of one pattern # case $1 in gnu) X=g/javax_comm/s+javax_comm+gnu_io+g ;; javax) X=g/gnu_io/s+gnu_io+javax_comm+g ;; *) echo;echo;echo From the top rxtx directory run;echo;echo -e \\t./ChangePackage.sh gnu;echo -e \\t\\tor;echo -e \\t./ChangePackage.sh javax;echo;echo; exit 0 ;; esac # # ed will be used to keep the owner and mode of the files unchanged. # We have run the ed-script for the characters '.' '/' as well. # "tr _ $D" do the change. # find . -type f -a -print | grep -v $0 | (while read F ; do ( echo $X; echo $X| tr _ /; echo $X| tr _ .; echo w; echo q ) | ed $F 2>&1 >/dev/null done ) # # Now we do little changes at the Makefiles. Hope that all we need. # find . -name Makefile\* -a -print | (while read F ; do cat < References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: On Thu, 7 Aug 2008, Lew L wrote: > As a matter of interest is the Sun Comm API documentation available > somewhere? I have tried the Sun site but it seems to have been removed. > > Unless I have missed the documentation for RXTX? I javadocced the RXTX > source but information (to me) is minimal. > Somewhere I got the impression that the Sun Comm API docs is, or was, > compatible with RXTX, what is the best docs to use in conjuntion with RXTX > and where may the be available? > Hi Lew, The documentation on Sun's website is accurate. The changes that are problematic in 3.0 are on the backside which rxtx used to plug into. http://java.sun.com/products/javacomm/reference/api/index.html CommPortIdentifier may have some minor differences (judging by the authors notes). -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Aug 6 21:46:08 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:46:08 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > If javax.comm.properties is properly installed and you are using a 2.0 version of Sun's commapi with rxtx 2.0, you should not see the library attempt to load libSolarisSerialParallel.so. Sun CommAPI 3.0 will not work with any version of rxtx as it is hard coded to use the shared library. See the INSTALL file with rxtx-2.0 source for more help with the properties file. -- Trent Jarvi tjarvi at qbang.org From jlar310 at gmail.com Thu Aug 7 06:32:06 2008 From: jlar310 at gmail.com (Jeff) Date: Thu, 7 Aug 2008 07:32:06 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > Jeff wrote: >> >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >> wrote: >> >>> >>> Jeff wrote: >>> >>>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>> wrote: >>>> >>>> >>>> >>>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things much > easier for me. I'm not sure why he's still using the javax compatible code. > He's a small operation. Re-writing the code to use gnu namespace sounds like > a major overhaul. Was it? I found it quite easy. In fact, in order to accommodate the transition, I actually separated all of the code that deals directly with the Comm API or RXTX into a helper class. The helper class was then coded to use reflection to determine which library was available and then instantiate the necessary objects. No direct imports of either library are used. The main application just needs to get it's hands on the IO streams and need not deal directly with the libraries. Other programs may not be so simple... But this doesn't really help you unless your vendor forks over the source code... -- Jeff From rick_knight at rlknight.com Thu Aug 7 09:47:12 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Thu, 07 Aug 2008 08:47:12 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: <489B1900.10108@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >>> wrote: >>> >>> >>>> Jeff wrote: >>>> >>>> >>>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>>> copy of the comm.api and I've copied the library >>>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>>> into the proper places. When I try to run the application, I get this >>>>>> error... >>>>>> >>>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>>> /usr/lib/libSolarisSerialParallel.so: >>>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>>> little-endian (Possible cause: endianness mismatch) >>>>>> Caught java.lang.UnsatisfiedLinkError: >>>>>> >>>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>>> >>>>>> while loading driver com.sun.comm.SolarisDriver >>>>>> >>>>>> Is there a way around this error? >>>>>> >>>>>> >>>>>> >>>>> What host OS are you running? From your original post it looks like 32 >>>>> bit Linux. >>>>> >>>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>>> depending on the underlying hardware architecture as well. >>>>> >>>>> >>>>> >>>>> >>>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>>> >>>> >>>> >>> I don't think Sun did binary libraries for Linux in the 2.0 version. >>> Can someone with more historical experience than I confirm that? >>> >>> I recently tried to port a Comm API application from Solaris sparc to >>> Linux x86 and likewise could not get my hands on the binary libraries. >>> I eventually just re-wrote the code to use the gnu namespace packages >>> and rxtx 2.1. >>> >>> What I don't understand is why your application vendor does not >>> provide everything you need to run their software. >>> >>> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >>> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >>> /usr/java/default which is actually a softlink to >>> /usr/java/jre1.6.0_05. >>> >>> >>> >> Jeff, >> >> I would like for my vendor to switch to rxtx 2.1. It would make things much >> easier for me. I'm not sure why he's still using the javax compatible code. >> He's a small operation. Re-writing the code to use gnu namespace sounds like >> a major overhaul. Was it? >> > > I found it quite easy. In fact, in order to accommodate the > transition, I actually separated all of the code that deals directly > with the Comm API or RXTX into a helper class. The helper class was > then coded to use reflection to determine which library was available > and then instantiate the necessary objects. No direct imports of > either library are used. The main application just needs to get it's > hands on the IO streams and need not deal directly with the libraries. > Other programs may not be so simple... > > But this doesn't really help you unless your vendor forks over the > source code... > > Jeff, This may not help me directly, but I'm going to forward this thread to the vendor. I think he'll be open to making things work. Thanks again, Rick Knight From agusmunioz at gmail.com Thu Aug 7 16:39:51 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Thu, 7 Aug 2008 19:39:51 -0300 Subject: [Rxtx] How to send ack? Message-ID: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Hi, I'm still learning about serial communication and I have some doubts. I've got this question about how to do the following thing in rxtx. I have this hardware that connect to a PC using a serial port. These hardware receives data from a telephone line, proccess it, and then send it forward to the serial port. I've used a program named wincomm that shows what information is send it through the serial port and I have the nex behaviour: The hardware has a buffer where all data is stored, that cannot be sent it through the seria port. The program reads the first data send it by the hardware, and keep reading the same data always. There is a button in the application that says enable Ack, and when I click, then the hardware start to send all the stored information, and all the information is shown. I write a class, using rxtx that reads the serial port, and the same thing happens, it remains reading the same (first) data all the time. And I thing something like the enable Ack I'm missing. How can I do this enable Ack from my java code using rxtx? Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080807/e0a0f9a1/attachment-0025.html From ajmas at sympatico.ca Thu Aug 7 18:26:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 7 Aug 2008 20:26:41 -0400 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: <4BF42297-81E2-4BB8-A89F-1D43588379AE@sympatico.ca> On 6-Aug-08, at 19:40 , Bruce Boyes wrote: >> Unless I have missed the documentation for RXTX? I javadocced the >> RXTX >> source but information (to me) is minimal. >> Somewhere I got the impression that the Sun Comm API docs is, or was, >> compatible with RXTX, what is the best docs to use in conjuntion >> with RXTX >> and where may the be available? > > Yeah, this is one of my concerns/beefs. There is little documentation > for RXTX and it isn't just the same as javaxcomm. > > I would be willing to help out writing docs for RXTX! Yes really... > esp if we can fix the Bluetooth issues. If you want to contribute documentation then the best place to do that is the wiki. If there is anything missing or that could be improved on then please do so. If there are any points that you would like to see improved, for which you don't have the knowledge then ask on the mailing list for a volunteer. Andre From florianmanschwetus at gmx.de Fri Aug 8 03:04:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Fri, 08 Aug 2008 11:04:14 +0200 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Message-ID: <489C0C0E.2020401@gmx.de> Agustin Mu?oz schrieb: > Hi, I'm still learning about serial communication and I have some > doubts. I've got this question about how to do the following thing in rxtx. > I have this hardware that connect to a PC using a serial port. These > hardware receives data from a telephone line, proccess it, and then send > it forward to the serial port. I've used a program named wincomm that > shows what information is send it through the serial port and I have the > nex behaviour: > > The hardware has a buffer where all data is stored, that cannot be sent > it through the seria port. > The program reads the first data send it by the hardware, and keep > reading the same data always. > There is a button in the application that says enable Ack, and when I > click, then the hardware start to send all the stored information, and > all the information is shown. > > I write a class, using rxtx that reads the serial port, and the same > thing happens, it remains reading the same (first) data all the time. > And I thing something like the enable Ack I'm missing. > How can I do this enable Ack from my java code using rxtx? Afaik, a look at man ascii reveals: Okt Dez Hex Char 006 6 06 ACK So, i hope this will do the job: send(6); florian > > Thanks in advance > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/5b4965f8/attachment-0025.bin From agusmunioz at gmail.com Fri Aug 8 16:31:00 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 19:31:00 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <489C0C0E.2020401@gmx.de> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> Message-ID: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Hi Florian, thanks for the answer. By send(6) you mean to get the port OutputStream and write a 6? I try that but it didn't work. Any suggestion? Thanks On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < florianmanschwetus at gmx.de> wrote: > Agustin Mu?oz schrieb: > > Hi, I'm still learning about serial communication and I have some doubts. >> I've got this question about how to do the following thing in rxtx. >> I have this hardware that connect to a PC using a serial port. These >> hardware receives data from a telephone line, proccess it, and then send it >> forward to the serial port. I've used a program named wincomm that shows >> what information is send it through the serial port and I have the nex >> behaviour: >> >> The hardware has a buffer where all data is stored, that cannot be sent >> it through the seria port. >> The program reads the first data send it by the hardware, and keep reading >> the same data always. >> There is a button in the application that says enable Ack, and when I >> click, then the hardware start to send all the stored information, and all >> the information is shown. >> >> I write a class, using rxtx that reads the serial port, and the same thing >> happens, it remains reading the same (first) data all the time. And I thing >> something like the enable Ack I'm missing. >> How can I do this enable Ack from my java code using rxtx? >> > Afaik, a look at man ascii reveals: > Okt Dez Hex Char > 006 6 06 ACK > So, i hope this will do the job: > send(6); > > florian > >> >> Thanks in advance >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/7f3fba42/attachment-0024.html From agusmunioz at gmail.com Fri Aug 8 18:39:27 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 21:39:27 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Message-ID: <988288430808081739x7f9e7889id82591d5a9e2b4f6@mail.gmail.com> Ok, Florian, it works!! my problem was that I've been sending, through the OutputStream, the bytes of 6 as a string: out.write("6".getBytes()); but then I realized that you can write an int on an OuptuStream, so I tried that and It works: out.write(6); Thank you for the guidance!! On Fri, Aug 8, 2008 at 7:31 PM, Agustin Mu?oz wrote: > Hi Florian, thanks for the answer. By send(6) you mean to get the port > OutputStream and write a 6? > > I try that but it didn't work. > > Any suggestion? > > Thanks > > > On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < > florianmanschwetus at gmx.de> wrote: > >> Agustin Mu?oz schrieb: >> >> Hi, I'm still learning about serial communication and I have some doubts. >>> I've got this question about how to do the following thing in rxtx. >>> I have this hardware that connect to a PC using a serial port. These >>> hardware receives data from a telephone line, proccess it, and then send it >>> forward to the serial port. I've used a program named wincomm that shows >>> what information is send it through the serial port and I have the nex >>> behaviour: >>> >>> The hardware has a buffer where all data is stored, that cannot be sent >>> it through the seria port. >>> The program reads the first data send it by the hardware, and keep >>> reading the same data always. >>> There is a button in the application that says enable Ack, and when I >>> click, then the hardware start to send all the stored information, and all >>> the information is shown. >>> >>> I write a class, using rxtx that reads the serial port, and the same >>> thing happens, it remains reading the same (first) data all the time. And I >>> thing something like the enable Ack I'm missing. >>> How can I do this enable Ack from my java code using rxtx? >>> >> Afaik, a look at man ascii reveals: >> Okt Dez Hex Char >> 006 6 06 ACK >> So, i hope this will do the job: >> send(6); >> >> florian >> >>> >>> Thanks in advance >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/b918ab3d/attachment-0024.html From florianmanschwetus at gmx.de Sat Aug 9 00:45:43 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Sat, 09 Aug 2008 08:45:43 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4899667C.6010706@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> Message-ID: <489D3D17.9090209@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >> Florian Manschwetus wrote: >>> Ok, sounds fine for the receiving problem. >>> But why i have to wait after each byte when sending a command squence? >>> (the for loop in send command) >> >> Hi Florian, >> I'd imagine you probably don't! You could send all bytes in one go and >> RXTX would send them. The problem is most probably the other end: >> perhaps it has a really small buffer, some non-standard UART, or a >> crazy timing issue. If you attach a terminal to your output and send >> all the bytes of a command in one go they should appear no problem. >> >> Regards, >> Michael Erskine. >> > correct with a terminal on the other end it works, my idea was that this > basic baud has some influence. Could some one explain what it is for? > > Florian To make it more clear, my problem is that i can't use: outputStream.write(byte[]); => Beamer doesn't understand the sequence. (mostly no answer when he answers then *001) when i use this construct instead: for (int i = 0; i < command.length; i++) { this.outputStream.write(command[i]); try { Thread.sleep(25); } catch (InterruptedException e) { // TODO Auto-generated catch block e.printStackTrace(); } } it works nearly reliable. So what could it be? This Basic Baud is what exactly? Florian -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080809/692304ee/attachment-0024.bin From tjarvi at qbang.org Sat Aug 9 16:37:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Aug 2008 16:37:19 -0600 (MDT) Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489D3D17.9090209@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> <489D3D17.9090209@gmx.de> Message-ID: On Sat, 9 Aug 2008, Florian Manschwetus wrote: > Florian Manschwetus schrieb: >> Michael Erskine schrieb: >>> Florian Manschwetus wrote: >>>> Ok, sounds fine for the receiving problem. >>>> But why i have to wait after each byte when sending a command squence? >>>> (the for loop in send command) >>> >>> Hi Florian, >>> I'd imagine you probably don't! You could send all bytes in one go and >>> RXTX would send them. The problem is most probably the other end: perhaps >>> it has a really small buffer, some non-standard UART, or a crazy timing >>> issue. If you attach a terminal to your output and send all the bytes of a >>> command in one go they should appear no problem. >>> >>> Regards, >>> Michael Erskine. >>> >> correct with a terminal on the other end it works, my idea was that this >> basic baud has some influence. Could some one explain what it is for? >> >> Florian > To make it more clear, > my problem is that i can't use: > outputStream.write(byte[]); > => Beamer doesn't understand the sequence. (mostly no answer when he answers > then *001) > > when i use this construct instead: > > for (int i = 0; i < command.length; i++) { > this.outputStream.write(command[i]); > try { > Thread.sleep(25); > } catch (InterruptedException e) { > // TODO Auto-generated catch block > e.printStackTrace(); > } > } > > it works nearly reliable. > > So what could it be? This Basic Baud is what exactly? > I suspect you are using the 'moon protocol' and don't know it. RXTX enables this by default. The buffer on the other end is first in first out while reading. If the buffer is full, the bits are hand carried to the moon and burried. Then if the other side reads a couple bytes, two more bytes go into the buffer followed by more moon protocol. The resulting array of bytes the other side reads may appear to be scrambled until you go to the moon, get the bits and insert them in the right place. Flow control can prevent the default moon protocol and throttles the communiation by almost writing a byte at a time as need be. Hardware flow control is preferable but software flow control should also work. Read and write can appear to hang if the other side is not connected. This is why we don't enable them all the time. If you can't use flow control, you have to take care with the moon protocol and give the other side time to read. That is what your slower version of write is doing. -- Trent Jarvi tjarvi at qbang.org From rxtx at allenjb.me.uk Mon Aug 11 08:06:36 2008 From: rxtx at allenjb.me.uk (AllenJB) Date: Mon, 11 Aug 2008 15:06:36 +0100 Subject: [Rxtx] Disabling EV_RXFLAG Message-ID: <48A0476C.2090800@allenjb.me.uk> Hi all, I'm working with a device which does not use an EvtChar and need to disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an event mask of FD 01 00 00. The reference software I have uses FB 00 00 00. With the rxtx mask I get framing errors which I believe are caused when the EvtChar is received. Is there currently a way with rxtx (I've using rxtx from Java) to disable EV_RXFLAG? If not from Java, where would I start if I wanted to turn the EV_RXFLAG option off in the C code? I've had a grep of the rxtx source code, but I can't see where EV_RXFLAG is being set. Thanks in advance, AllenJB From tjarvi at qbang.org Mon Aug 11 14:17:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Aug 2008 14:17:27 -0600 (MDT) Subject: [Rxtx] Disabling EV_RXFLAG In-Reply-To: <48A0476C.2090800@allenjb.me.uk> References: <48A0476C.2090800@allenjb.me.uk> Message-ID: On Mon, 11 Aug 2008, AllenJB wrote: > Hi all, > > I'm working with a device which does not use an EvtChar and need to > disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an > event mask of FD 01 00 00. The reference software I have uses FB 00 00 > 00. With the rxtx mask I get framing errors which I believe are caused > when the EvtChar is received. > > Is there currently a way with rxtx (I've using rxtx from Java) to > disable EV_RXFLAG? > > If not from Java, where would I start if I wanted to turn the EV_RXFLAG > option off in the C code? I've had a grep of the rxtx source code, but I > can't see where EV_RXFLAG is being set. > > Thanks in advance, > > AllenJB Hi Allen, I'd look at termios.c::tcsetattr() and termios.c::FillDCB() -- Trent Jarvi tjarvi at qbang.org From superdadusa at gmail.com Tue Aug 12 13:57:32 2008 From: superdadusa at gmail.com (John Choi) Date: Tue, 12 Aug 2008 13:57:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. Message-ID: Hi all, Just let you all know I just start to learn Java. I have download the serial comm package and the source code from open source communities.. I was able to verify with the given message string via serial monitor. when the given message string sends to the serial port then the character return added to the end of string by default if I use "Hello World" however if I changed to something else other than "Hello, World" there is no character return add to the end of string. I thing the library download from rxtx.org has implemented for the special strings. I can do like "login\n" in the string message to make character return but I don't want to add this individual custom character for each command return in every static message string I send, Can any who have done this might help me? Basically, something like this,, Write and add function to the program write a command, Reads the respond from a serial device.. Function handles multiple messages, Write: "com open" Read: Welcome to my world" expected Write: "admin" Read: Password?, expected Write: "admin" Read: you are successfully login terminal, expected. And I need to add a separate function handler handles a character return add to the each command above. If anyone can help this I can do the reset? Thank you in advance, John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0020.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SerialIO.java Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0020.pl From Steffen.DETTMER at ingenico.com Wed Aug 13 02:16:38 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 13 Aug 2008 10:16:38 +0200 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: References: Message-ID: <20080813081638.GA25412@elberon.bln.de.ingenico.com> * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > I can do like "login\n" in the string message to make character > return but I don't want to add this individual custom character > for each command return in every static message string I send, and why not?! > Can any who have done this might help me? what's about with writing a small wrapper function adding the carriage return? However, this would be slow, because either you call write two times (very bad) or the string needs to be copied, \n appended and written (since you are using Java Performance probably isn't so critical). Personally I would write `"login\n"' and `username + "\n"' etc., because since it is part of the command it should be part of the command definition string. > Basically, something like this,, Write and add function to the program write > a command, Reads the respond from a serial device.. correctly reading a `line' is more difficult. If you cannot make assumptions about timeouts and/or you need to have low delay, you need to read byte wise. If you need to save CPU resources you might need to add some buffering layer that you can read byte-wise but that is reading blockwise with some small timeout (lets say for serial lines something around byte transmission time times three or so). > /* > * To change this template, choose Tools | Templates > * and open the template in the editor. > */ :) > package joliba; > > /** > * > * @author root > */ :) > // derived from SUN's examples in the javax.comm package > import java.io.*; > import java.util.*; > //import javax.comm.*; // for SUN's serial/parallel port libraries > import gnu.io.*; // for rxtxSerial library > > public class SerialIO implements Runnable, SerialPortEventListener { > static CommPortIdentifier portId; > static CommPortIdentifier saveportId; > static Enumeration portList; > InputStream inputStream; > SerialPort serialPort; > Thread readThread; You need a thread for your synchronous RPC-style protocol? > static String messageString = "Hello, world!"; > static OutputStream outputStream; > static boolean outputBufferEmptyFlag = false; > > public static void main(String[] args) { > boolean portFound = false; > String defaultPort; > > // determine the name of the serial port on several operating systems > String osname = System.getProperty("os.name","").toLowerCase(); > if ( osname.startsWith("windows") ) { > // windows > defaultPort = "COM1"; > } else if (osname.startsWith("linux")) { > // linux > defaultPort = "/dev/ttyS0"; > } else if ( osname.startsWith("mac") ) { > // mac > defaultPort = "????"; > } else { > System.out.println("Sorry, your operating system is not supported"); > return; > } Is such a construction recommended? Isn't there some abstraction (like COM1 working on any platform)? [...] > try { > // activate the OUTPUT_BUFFER_EMPTY notifier > serialPort.notifyOnOutputEmpty(true); > } catch (Exception e) { > System.out.println("Error setting event notification"); > System.out.println(e.toString()); > System.exit(-1); > } I doubt that -1 is defined, probably some 127 or so would be the result, maybe better simply `throw e'? > public void writetoport() { > System.out.println("Writing \""+messageString+"\" to "+serialPort.getName()); > try { > // write string to serial port > outputStream.write(messageString.getBytes()); > } catch (IOException e) {} > } maybe something like /** * Writes the given output string and an additional carriage * return to the current outputStream. */ public void writeStringToPort( /** The output string (without CR). */ String output ) throws IOException { String outputLine = output + "\n"; outputStream.write(outputLine.getBytes()); } ? > > public SerialIO() { > // initalize serial port > try { > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > } catch (PortInUseException e) {} if the port is in use, you continue? Wonder that this works in Java, I would assume serialPort beeing uninitialized which AFAIK is an error in Java. > try { > inputStream = serialPort.getInputStream(); > } catch (IOException e) {} > > try { > serialPort.addEventListener(this); > } catch (TooManyListenersException e) {} > > // activate the DATA_AVAILABLE notifier > serialPort.notifyOnDataAvailable(true); > > try { > // set port parameters > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > } catch (UnsupportedCommOperationException e) {} > > // start the read thread > readThread = new Thread(this); > readThread.start(); > > } I think in all those exception cases you can abort, because it is unlikely that ignoring those errors allow a successful continuation, so in this case maybe it would be better to add a throw clause to the method. > public void run() { > // first thing in the thread, we initialize the write operation > initwritetoport(); > try { > while (true) { > // write string to port, the serialEvent will read it > writetoport(); > Thread.sleep(1000); > } > } catch (InterruptedException e) {} > } Does this make sense? Your `SimpleReadApp' writes one and the same string each second? > public void serialEvent(SerialPortEvent event) { > switch (event.getEventType()) { > case SerialPortEvent.BI: > case SerialPortEvent.OE: > case SerialPortEvent.FE: > case SerialPortEvent.PE: > case SerialPortEvent.CD: > case SerialPortEvent.CTS: > case SerialPortEvent.DSR: > case SerialPortEvent.RI: > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > break; > case SerialPortEvent.DATA_AVAILABLE: > // we get here if data has been received > byte[] readBuffer = new byte[20]; > try { > // read data > while (inputStream.available() > 0) { > int numBytes = inputStream.read(readBuffer); > } > // print data > String result = new String(readBuffer); > System.out.println("Read: "+result); > } catch (IOException e) {} I doubt that this is correct. I would assume you will get a 20 bytes result always, if more bytes would be available they would be printed in a second line but if less bytes are read I'd assume that the buffer/result contains zero bytes from implicite readBuffer contents initialisation (zero is no string terminator in Java AFAIK). > break; > } > } > } oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From florianmanschwetus at gmx.de Wed Aug 13 06:09:31 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 13 Aug 2008 14:09:31 +0200 Subject: [Rxtx] someone has seen such errors? Message-ID: <48A2CEFB.90007@gmx.de> I mean my communication mostly works, but it is far from perfect could this be the reason? Florian Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/949b9947/attachment-0020.bin From superdadusa at gmail.com Wed Aug 13 08:40:32 2008 From: superdadusa at gmail.com (John Choi) Date: Wed, 13 Aug 2008 08:40:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: <20080813081638.GA25412@elberon.bln.de.ingenico.com> References: <20080813081638.GA25412@elberon.bln.de.ingenico.com> Message-ID: Thank you so much Steffen and I will try that suggestion. John On 8/13/08, Steffen DETTMER wrote: > > * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > > I can do like "login\n" in the string message to make character > > return but I don't want to add this individual custom character > > for each command return in every static message string I send, > > and why not?! > > > Can any who have done this might help me? > > what's about with writing a small wrapper function adding the > carriage return? > However, this would be slow, because either you call write two > times (very bad) or the string needs to be copied, \n appended > and written (since you are using Java Performance probably isn't > so critical). > > Personally I would write `"login\n"' and `username + "\n"' etc., > because since it is part of the command it should be part of the > command definition string. > > > Basically, something like this,, Write and add function to the program > write > > a command, Reads the respond from a serial device.. > > correctly reading a `line' is more difficult. If you cannot make > assumptions about timeouts and/or you need to have low delay, you > need to read byte wise. If you need to save CPU resources you > might need to add some buffering layer that you can read > byte-wise but that is reading blockwise with some small timeout > (lets say for serial lines something around byte transmission > time times three or so). > > > /* > > * To change this template, choose Tools | Templates > > * and open the template in the editor. > > */ > > :) > > > package joliba; > > > > /** > > * > > * @author root > > */ > > :) > > > // derived from SUN's examples in the javax.comm package > > import java.io.*; > > import java.util.*; > > //import javax.comm.*; // for SUN's serial/parallel port libraries > > import gnu.io.*; // for rxtxSerial library > > > > public class SerialIO implements Runnable, SerialPortEventListener { > > static CommPortIdentifier portId; > > static CommPortIdentifier saveportId; > > static Enumeration portList; > > InputStream inputStream; > > SerialPort serialPort; > > Thread readThread; > > You need a thread for your synchronous RPC-style protocol? > > > static String messageString = "Hello, world!"; > > static OutputStream outputStream; > > static boolean outputBufferEmptyFlag = false; > > > > public static void main(String[] args) { > > boolean portFound = false; > > String defaultPort; > > > > // determine the name of the serial port on several operating > systems > > String osname = System.getProperty("os.name","").toLowerCase(); > > if ( osname.startsWith("windows") ) { > > // windows > > defaultPort = "COM1"; > > } else if (osname.startsWith("linux")) { > > // linux > > defaultPort = "/dev/ttyS0"; > > } else if ( osname.startsWith("mac") ) { > > // mac > > defaultPort = "????"; > > } else { > > System.out.println("Sorry, your operating system is not > supported"); > > return; > > } > > Is such a construction recommended? Isn't there some abstraction > (like COM1 working on any platform)? > > [...] > > try { > > // activate the OUTPUT_BUFFER_EMPTY notifier > > serialPort.notifyOnOutputEmpty(true); > > } catch (Exception e) { > > System.out.println("Error setting event notification"); > > System.out.println(e.toString()); > > System.exit(-1); > > } > > I doubt that -1 is defined, probably some 127 or so would be the > result, maybe better simply `throw e'? > > > public void writetoport() { > > System.out.println("Writing \""+messageString+"\" to > "+serialPort.getName()); > > try { > > // write string to serial port > > outputStream.write(messageString.getBytes()); > > } catch (IOException e) {} > > } > > maybe something like > > /** > * Writes the given output string and an additional carriage > * return to the current outputStream. > */ > public void > writeStringToPort( > /** The output string (without CR). */ > String output > ) throws IOException > { > String outputLine = output + "\n"; > outputStream.write(outputLine.getBytes()); > } > > ? > > > > > public SerialIO() { > > // initalize serial port > > try { > > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > > } catch (PortInUseException e) {} > > if the port is in use, you continue? Wonder that this works in > Java, I would assume serialPort beeing uninitialized which AFAIK > is an error in Java. > > > try { > > inputStream = serialPort.getInputStream(); > > } catch (IOException e) {} > > > > try { > > serialPort.addEventListener(this); > > } catch (TooManyListenersException e) {} > > > > // activate the DATA_AVAILABLE notifier > > serialPort.notifyOnDataAvailable(true); > > > > try { > > // set port parameters > > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > } catch (UnsupportedCommOperationException e) {} > > > > // start the read thread > > readThread = new Thread(this); > > readThread.start(); > > > > } > > I think in all those exception cases you can abort, because it is > unlikely that ignoring those errors allow a successful > continuation, so in this case maybe it would be better to add a > throw clause to the method. > > > public void run() { > > // first thing in the thread, we initialize the write operation > > initwritetoport(); > > try { > > while (true) { > > // write string to port, the serialEvent will read it > > writetoport(); > > Thread.sleep(1000); > > } > > } catch (InterruptedException e) {} > > } > > Does this make sense? Your `SimpleReadApp' writes one and the > same string each second? > > > public void serialEvent(SerialPortEvent event) { > > switch (event.getEventType()) { > > case SerialPortEvent.BI: > > case SerialPortEvent.OE: > > case SerialPortEvent.FE: > > case SerialPortEvent.PE: > > case SerialPortEvent.CD: > > case SerialPortEvent.CTS: > > case SerialPortEvent.DSR: > > case SerialPortEvent.RI: > > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > > break; > > case SerialPortEvent.DATA_AVAILABLE: > > // we get here if data has been received > > byte[] readBuffer = new byte[20]; > > try { > > // read data > > while (inputStream.available() > 0) { > > int numBytes = inputStream.read(readBuffer); > > } > > // print data > > String result = new String(readBuffer); > > System.out.println("Read: "+result); > > } catch (IOException e) {} > > I doubt that this is correct. I would assume you will get a 20 > bytes result always, if more bytes would be available they would > be printed in a second line but if less bytes are read I'd assume > that the buffer/result contains zero bytes from implicite > readBuffer contents initialisation (zero is no string terminator > in Java AFAIK). > > > break; > > } > > } > > } > > oki, > > Steffen > > About Ingenico Throughout the world businesses rely on Ingenico for secure > and expedient electronic transaction acceptance. Ingenico products leverage > proven technology, established standards and unparalleled ergonomics to > provide optimal reliability, versatility and usability. This comprehensive > range of products is complemented by a global array of services and > partnerships, enabling businesses in a number of vertical sectors to accept > transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged > information. If you are not the addressee or authorized to receive this for > the addressee, you must not use, copy, disclose or take any action based on > this message or any information herein. If you have received this message in > error, please advise the sender immediately by reply e-mail and delete this > message. Thank you for your cooperation. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/73c4135c/attachment-0019.html From ajmas at sympatico.ca Sat Aug 16 07:15:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 09:15:41 -0400 Subject: [Rxtx] someone has seen such errors? In-Reply-To: <48A2CEFB.90007@gmx.de> References: <48A2CEFB.90007@gmx.de> Message-ID: <43B5E8DA-1D93-4D90-809B-AAF35FF724C5@sympatico.ca> On 13-Aug-08, at 08:09 , Florian Manschwetus wrote: > I mean my communication mostly works, but it is far from perfect > could this be the reason? > > Florian > > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control Judging by the error messages this looks related to the driver you are using. Do a search for the following string with you favourite search engine, it should turn up a few hits: ftdi_set_termios FAILED to set databits/stopbits/parity Andre From ajmas at sympatico.ca Sat Aug 16 19:12:04 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 21:12:04 -0400 Subject: [Rxtx] Using SerialPortEvent? Message-ID: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Hi, Could someone tell me how I should be using the SerialPortEvent? Am I meant to be waiting for data and then simply reading from the inputstream? If this is the case why no just block on an inputstream read? Andr? From tjarvi at qbang.org Sat Aug 16 19:41:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 16 Aug 2008 19:41:13 -0600 (MDT) Subject: [Rxtx] Using SerialPortEvent? In-Reply-To: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> References: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Message-ID: On Sat, 16 Aug 2008, Andre-John Mas wrote: > Hi, > > Could someone tell me how I should be using the SerialPortEvent? Am I > meant to be waiting for data and then simply reading from the > inputstream? If this is the case why no just block on an inputstream > read? > Polling for data is fine also. It really depends upon what you are trying to do. For instance, if you require x bytes before reading, you can start polling after data is available. If you read on the same thread as your GUI and are waiting for data in a read, the results may be less than desirable. Java programming is 'usually' event driven rather than polling based. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sat Aug 16 20:10:39 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 22:10:39 -0400 Subject: [Rxtx] Using SerialPortEvent? In-Reply-To: References: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Message-ID: <3E495D4C-BB28-4845-A6AB-984C9A826BDF@sympatico.ca> On 16-Aug-08, at 21:41 , Trent Jarvi wrote: > On Sat, 16 Aug 2008, Andre-John Mas wrote: > >> Hi, >> >> Could someone tell me how I should be using the SerialPortEvent? Am I >> meant to be waiting for data and then simply reading from the >> inputstream? If this is the case why no just block on an inputstream >> read? >> > > Polling for data is fine also. It really depends upon what you are > trying to do. For instance, if you require x bytes before reading, > you can start polling after data is available. If you read on the > same thread as your GUI and are waiting for data in a read, the > results may be less than desirable. > > Java programming is 'usually' event driven rather than polling based. Sounds good. I thought I would use this opportunity to provide a event based version of the TwoWaySerialComm example. Could you just validate it before I add it to the Wiki: package ajmas74.experimental; import gnu.io.CommPort; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; import gnu.io.SerialPortEvent; import gnu.io.SerialPortEventListener; import java.io.IOException; import java.io.InputStream; import java.io.OutputStream; /** * This version of the TwoWaySerialComm example makes use of the * SerialPortEventListener to avoid polling. * * @author ajmas * */ public class TwoWaySerialComm { public TwoWaySerialComm() { super(); } void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { CommPort commPort = portIdentifier.open(this.getClass().getName(),2000); if ( commPort instanceof SerialPort ) { SerialPort serialPort = (SerialPort) commPort; serialPort .setSerialPortParams (57600 ,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); (new Thread(new SerialWriter(out))).start(); serialPort.addEventListener(new SerialReader(in)); } else { System.out.println("Error: Only serial ports are handled by this example."); } } } /** * Handles the input coming from the serial port. A new line character * is treated as the end of a block in this example. */ public static class SerialReader implements SerialPortEventListener { private InputStream in; private byte[] buffer = new byte[1024]; public SerialReader ( InputStream in ) { this.in = in; } public void serialEvent(SerialPortEvent arg0) { int data; try { int len = 0; while ( ( data = in.read()) > -1 ) { if ( data != '\n' ) { break; } buffer[len++] = (byte) data; } System.out.print(new String(buffer,0,len)); } catch ( IOException e ) { e.printStackTrace(); System.exit(-1); } } } /** */ public static class SerialWriter implements Runnable { OutputStream out; public SerialWriter ( OutputStream out ) { this.out = out; } public void run () { try { int c = 0; while ( ( c = System.in.read()) > -1 ) { this.out.write(c); } } catch ( IOException e ) { e.printStackTrace(); System.exit(-1); } } } public static void main ( String[] args ) { try { (new TwoWaySerialComm()).connect("COM3"); } catch ( Exception e ) { e.printStackTrace(); } } } From lfarkas at lfarkas.org Tue Aug 19 07:32:59 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Tue, 19 Aug 2008 15:32:59 +0200 Subject: [Rxtx] JNI or CNI Message-ID: <48AACB8B.9060606@lfarkas.org> hi, what is the current recommended way to rxtx on linux JNI or it's better to use CNI? is the CNI version fully functional and the same level as the JNI? i currently try to make a rhel/centos/fedora rpm for rxtx but has many problems with the standard dir structure. yours. -- Levente "Si vis pacem para bellum!" From lfarkas at lfarkas.org Tue Aug 19 08:47:34 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Tue, 19 Aug 2008 16:47:34 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel Message-ID: <48AADD06.7040809@lfarkas.org> hi, newer or not so newer linux kernel do not contain the UTS_RELEASE so the current rxtx is not compile on the latest kernels. even if it's commented out in the cvs configure there are other places. i attcahed a patch which fix it (or at least doesn't cause error at non-debug build). ps. is there any plan to the new 2.1-8 release in the near future? there are many changes (at least the license change in all file and in this case create a diff is very difficult)? the latest release more then 2 years old:-( -- Levente "Si vis pacem para bellum!" -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-2.1-uts.patch Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080819/ab5d38ac/attachment-0013.pl From ajmas at sympatico.ca Tue Aug 19 16:21:53 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 19 Aug 2008 18:21:53 -0400 Subject: [Rxtx] Event based example Message-ID: <24735BFB-B088-4B84-8173-FE98DF63B12F@sympatico.ca> Hi, I have just posted an example of using SerialPortEventListener in the Wiki: http://rxtx.qbang.org/wiki/index.php/Event_Based_Two_Way_Communication If you see any issues please could you let me know, or makes the changes. Andre From Martin.Oberhuber at windriver.com Fri Aug 22 04:02:24 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 22 Aug 2008 12:02:24 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <48AADD06.7040809@lfarkas.org> References: <48AADD06.7040809@lfarkas.org> Message-ID: <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> Farkas, there are indeed efforts to get a new RXTX release out the door. Your experience as a package maintainer would likely be helpful during these efforts, since I'd think it makes sense to keep the patches minimal that you must make to have the source compile in your environment. What are the things that you find problematic, apart from the UTS thing that you have mentioned before? What is the timing that you have in mind for your package? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Farkas Levente > Sent: Tuesday, August 19, 2008 4:48 PM > To: rxtx at qbang.org > Subject: [Rxtx] UTS_RELEASE not defined in newer kernel > > hi, > newer or not so newer linux kernel do not contain the > UTS_RELEASE so the > current rxtx is not compile on the latest kernels. even if it's > commented out in the cvs configure there are other places. > i attcahed a patch which fix it (or at least doesn't cause error at > non-debug build). > > ps. is there any plan to the new 2.1-8 release in the near > future? there > are many changes (at least the license change in all file and in this > case create a diff is very difficult)? the latest release more then 2 > years old:-( > > -- > Levente "Si vis pacem para bellum!" > From lfarkas at lfarkas.org Fri Aug 22 04:36:26 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Fri, 22 Aug 2008 12:36:26 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> References: <48AADD06.7040809@lfarkas.org> <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> Message-ID: <48AE96AA.6090505@lfarkas.org> hi, the packages already build for fedora-9 and centos-5 and here: http://www.lfarkas.org/linux/packages/ what i've to patch, the UTS, the configure script, but it's already fixed in the cvs (in another way) and the loadlibrary. the reasons for last one can be found here: https://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_files_that_use_JNI after we test it i'd like to add these packages to fedora and epel main repository (that's why it's be useful a new release after 2 years:-) imho versions are cheap and why not just release 2.1-8? the real code changes are minimal and if something critical bug found still can release 2.1-9:-) ps. and would be better to use simple number for version like 2.1-7 rather then 2.1-7v2. Oberhuber, Martin wrote: > Farkas, > > there are indeed efforts to get a new RXTX release out the > door. Your experience as a package maintainer would likely > be helpful during these efforts, since I'd think it makes > sense to keep the patches minimal that you must make to > have the source compile in your environment. > > What are the things that you find problematic, apart from > the UTS thing that you have mentioned before? > > What is the timing that you have in mind for your package? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >> On Behalf Of Farkas Levente >> Sent: Tuesday, August 19, 2008 4:48 PM >> To: rxtx at qbang.org >> Subject: [Rxtx] UTS_RELEASE not defined in newer kernel >> >> hi, >> newer or not so newer linux kernel do not contain the >> UTS_RELEASE so the >> current rxtx is not compile on the latest kernels. even if it's >> commented out in the cvs configure there are other places. >> i attcahed a patch which fix it (or at least doesn't cause error at >> non-debug build). >> >> ps. is there any plan to the new 2.1-8 release in the near >> future? there >> are many changes (at least the license change in all file and in this >> case create a diff is very difficult)? the latest release more then 2 >> years old:-( >> >> -- >> Levente "Si vis pacem para bellum!" >> -- Levente "Si vis pacem para bellum!" From tjarvi at qbang.org Fri Aug 22 18:50:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Aug 2008 18:50:32 -0600 (MDT) Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <48AE96AA.6090505@lfarkas.org> References: <48AADD06.7040809@lfarkas.org> <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> <48AE96AA.6090505@lfarkas.org> Message-ID: Hi Farkas, The v2 was simply the second build - no code changes. We are comming out with a new release shortly. I would encourage working with distros as you are. The building of rxtx turns out to be a bottle neck in quick releases. We do want stable releases that work for a year or more but I would have no problems with quicker cycles on developing work. I would have no problem working with someone that did builds that receive less testing more often but they do have to come out for multiple platforms from this end. Thanks for the links. On Fri, 22 Aug 2008, Farkas Levente wrote: > hi, > the packages already build for fedora-9 and centos-5 and here: > http://www.lfarkas.org/linux/packages/ > what i've to patch, the UTS, the configure script, but it's already > fixed in the cvs (in another way) and the loadlibrary. the reasons for > last one can be found here: > https://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_files_that_use_JNI > after we test it i'd like to add these packages to fedora and epel main > repository (that's why it's be useful a new release after 2 years:-) > imho versions are cheap and why not just release 2.1-8? the real code > changes are minimal and if something critical bug found still can > release 2.1-9:-) > > ps. and would be better to use simple number for version like 2.1-7 > rather then 2.1-7v2. > > Oberhuber, Martin wrote: >> Farkas, >> >> there are indeed efforts to get a new RXTX release out the >> door. Your experience as a package maintainer would likely >> be helpful during these efforts, since I'd think it makes >> sense to keep the patches minimal that you must make to >> have the source compile in your environment. >> >> What are the things that you find problematic, apart from >> the UTS thing that you have mentioned before? >> >> What is the timing that you have in mind for your package? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >>> On Behalf Of Farkas Levente >>> Sent: Tuesday, August 19, 2008 4:48 PM >>> To: rxtx at qbang.org >>> Subject: [Rxtx] UTS_RELEASE not defined in newer kernel >>> >>> hi, >>> newer or not so newer linux kernel do not contain the >>> UTS_RELEASE so the >>> current rxtx is not compile on the latest kernels. even if it's >>> commented out in the cvs configure there are other places. >>> i attcahed a patch which fix it (or at least doesn't cause error at >>> non-debug build). >>> >>> ps. is there any plan to the new 2.1-8 release in the near >>> future? there >>> are many changes (at least the license change in all file and in this >>> case create a diff is very difficult)? the latest release more then 2 >>> years old:-( >>> >>> -- >>> Levente "Si vis pacem para bellum!" >>> > > > From andy at triera.net Sat Aug 23 15:17:44 2008 From: andy at triera.net (Andy Rozman) Date: Sat, 23 Aug 2008 21:17:44 +0000 Subject: [Rxtx] port not identified on FreeBSD In-Reply-To: References: Message-ID: <48B07E78.2030306@triera.net> Hi ! I have one small problem... I have started using FreeBSD in last few days and I have come accross a problem with rxtx on FreeBSD. I am using usb-to-serial converter, which is identified under FreeBSD without problem as ucom0, and creates link under /dev called ttyU0, which is correct way to be done under FreeBSD (if device would be unidentified it would be called ugen0 - as usb generic). Problem is that I say to rxtx to get my all serial ports this one is not among them. Which names are permissable under linux-like implementations? Which will be accepted as serial ports? Andy From tjarvi at qbang.org Sat Aug 23 13:57:45 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 23 Aug 2008 13:57:45 -0600 (MDT) Subject: [Rxtx] port not identified on FreeBSD In-Reply-To: <48B07E78.2030306@triera.net> References: <48B07E78.2030306@triera.net> Message-ID: On Sat, 23 Aug 2008, Andy Rozman wrote: > Hi ! > > I have one small problem... I have started using FreeBSD in last few > days and I have come accross a problem with rxtx on FreeBSD. > > I am using usb-to-serial converter, which is identified under FreeBSD > without problem as ucom0, and creates link under /dev called > ttyU0, which is correct way to be done under FreeBSD (if device would be > unidentified it would be called ugen0 - as usb generic). Problem is that > I say to rxtx to get my all serial ports this one is not among them. > Which names are permissable under linux-like implementations? Which will > be accepted as serial ports? > > Andy > Thanks Andy! We will add ttyU* to FreeBSD. For now you can use properties to enable the port. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting#How_does_rxtx_detect_ports.3F__Can_I_override_it.3F The fix: diff -u -r1.16.2.59 RXTXCommDriver.java --- RXTXCommDriver.java 18 Nov 2007 22:32:41 -0000 1.16.2.59 +++ RXTXCommDriver.java 23 Aug 2008 19:55:25 -0000 @@ -644,6 +644,7 @@ { String[] Temp = { "ttyd", //general purpose serial ports + "ttyU", //general purpose USB serial ports "cuaa", //dialout serial ports "ttyA", //Specialix SI/XIO dialin ports "cuaA", //Specialix SI/XIO dialout ports -- Trent Jarvi tjarvi at qbang.org From rick_knight at rlknight.com Mon Aug 4 13:25:10 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Mon, 04 Aug 2008 12:25:10 -0700 Subject: [Rxtx] Sun's Comm API? Message-ID: <48975796.4010600@rlknight.com> I have an application that requires the javax compatible version of RXTX and Sun's comm api. I've been able to download and extract the version of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api anywhere. Can someone tell me where I can find it? Or maybe send me a copy? Also, when I try to build RXTX, configure and make complete successfully but make install failes with this error libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 I've never come accross this error before. How can I get past it? Thanks, Rick From bboyes at systronix.com Mon Aug 4 19:10:01 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:10:01 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48975796.4010600@rlknight.com> References: <48975796.4010600@rlknight.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/cb9c6167/attachment-0029.html From bboyes at systronix.com Mon Aug 4 19:12:37 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:12:37 -0600 Subject: [Rxtx] Towards an RXTX release - CSR BT/USB chipset In-Reply-To: <488FB7E7.8000802@gmail.com> References: <460801A4097E3D4CA04CC64EE648584806C56CF0@ism-mail03.corp.ad.wrs.com> <13557-75390@sneakemail.com> <20980-23424@sneakemail.com> <488FB7E7.8000802@gmail.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/52236088/attachment-0029.html From tjarvi at qbang.org Mon Aug 4 19:42:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 19:42:21 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: On Mon, 4 Aug 2008, Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: > I have an application that requires the javax compatible > version of RXTX > and Sun's comm api. I've been able to download and extract > the version > of RXTX that I need (2.0-7pre2) but I can't find Sun's camm > api > anywhere. Can someone tell me where I can find it? Or maybe > send me a > > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm port > support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have just > a ZIP with only the .class JAR file - no source or docs), has a readme > with these comments: > > This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release.? The 2.0.3 release itself is > no longer distributed.? comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project.? The RxTx project (http://www.rxtx.org ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org) was opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support.? Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins.? Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > ? > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > I hope that is helpful! > It would be nice to work with Sun to resolve those longstanding issues. But it may not be practical unless the process goes as fast and painless as the grandfathering of commapi did. Another option may be the old kaffe extensions that moved to gnu classpathx. These don't have the native libraries but should provide the 2.0 interface and the javax.comm.properties mechansim for SPI. http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Mon Aug 4 20:23:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Mon, 04 Aug 2008 20:23:57 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4897B9BD.5070809@ergotech.com> Has there been any work/would it be possible, to layer a javacomm look-alike on top of the GNU code? The goal is not to move the javax code forward, but to emulate the "legacy" javax packages for people who still need this. Jim Trent Jarvi wrote: > On Mon, 4 Aug 2008, Bruce Boyes wrote: > >> At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible >> version of RXTX >> and Sun's comm api. I've been able to download and extract >> the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm >> api >> anywhere. Can someone tell me where I can find it? Or maybe >> send me a >> >> >> javaxcomm has had a sort of on-again off-again history. The windoze >> version has been languishing for years (literally) but there are newer >> versions for other OS's. >> >> We try to keep links on one of our help pages current: >> http://www.practicalembeddedjava.com/tools/javatools_list.html >> which gets you to here: >> http://java.sun.com/products/javacomm/ >> where it says in fact they no longer even support Windows and Mac: >> "Implementations of the API are currently available for Solaris SPARC, >> Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so >> someone could support it. But I guess that's part of the reason RXTX >> exists! >> >> So one of Sun's own products, SunSPOT, has to use RXTX to get comm port >> support. >> >> The version we use is 2.0 from 11/15/1998. I have posted it on our >> website, which is within the terms of the license agreement contained >> therein (as I understand it). >> >> The last version of javaxcomm for Windows, 2.0.3, (for which I have just >> a ZIP with only the .class JAR file - no source or docs), has a readme >> with these comments: >> >> This distribution contains the comm.jar file original part >> of the COMMAPI 2.0.3 release. The 2.0.3 release itself is >> no longer distributed. comm.jar, which contains the comm >> API java class files (eg. Sun's binary implementation of the >> interface classes), is being made available, unsupported, >> with no obligation to fix bugs, at the request of the RXTX >> project. The RxTx project (http://www.rxtx.org ), uses the >> comm.jar class files, but provides their own native library >> components to provide support for other platforms. >> >> The 2.0.3 comm.jar is being provided in this way because >> as of COMMAPI 3.x, the java binary implementation forked and >> became incompatible with the RxTx project's native code. >> Due to the lack of a clear business case, and to resource >> constraints, no additional resources are being >> provided to provide an alternative engineering solution >> at the time of writing. >> >> RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: >> >> Ultimately the COMMAPI would be better served if a Java >> Community Process JSR (http://www.jcp.org) was opened and >> the COMMAPI was rearchitected to provide a more pluggable >> framework to improve cross-platform support. Such an >> architecture would embody a better defined and better >> documented SPI interface, including a way for comm. ports >> to be revealed to the client application through the API >> via platform-aware plugins. Similarly, native code used >> to access comm port in general could be handled more >> flexibly using a plugin model, whereby on any platform, >> multiple native modules could be in use simultaneously. >> >> Since there are now various ways serial ports can be implemented >> and accessed, modular comm. port JNI native libraries would be >> of benefit insofar as removing the burden of over-generalization >> from any single native component, or inversely, by relieving the >> implicit constraint that comm. drivers be accessed only via a >> monolithic mechanism, such as the UNIX vnode interface. >> >> paul.klissner at sun.com >> 6/10/06 >> >> I hope that is helpful! >> > > It would be nice to work with Sun to resolve those longstanding issues. > But it may not be practical unless the process goes as fast and painless > as the grandfathering of commapi did. > > Another option may be the old kaffe extensions that moved to gnu > classpathx. These don't have the native libraries but should provide > the 2.0 interface and the javax.comm.properties mechansim for SPI. > > http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Mon Aug 4 21:09:15 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 21:09:15 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? Message-ID: Hi Jim, I will not step into the javax.comm namespace without Sun's explicite permission. I fully understand the pain point you are trying to address. In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm Linux) - which remains an integral part of rxtx. At the time it was a win for Sun and rxtx. The Sun commapi license is/was fairly clear that rxtx should not step into that namespace. It made sense as Sun was active in that space and rxtx may go into another namespace - it was an experiment in working with Sun. This may sound silly looking at something that happened almost 10 years ago. In a community of respect which Sun helped create, there is no question about what to do. I hope eventually Sun will step up and do a right thing too. I agree that this is hurting the API more than helping it. There are also questions about how to replace the API in the long term which includes HID support which isn't going well so far. Others that can't even look at Sun's javax.comm today and can look at Kaffe's contribution to classpathx can easily work around such restrictions. On Mon, 4 Aug 2008, Jim Redman wrote: > Has there been any work/would it be possible, to layer a javacomm > look-alike on top of the GNU code? > > The goal is not to move the javax code forward, but to emulate the > "legacy" javax packages for people who still need this. > > Jim > > Trent Jarvi wrote: >> >> It would be nice to work with Sun to resolve those longstanding issues. >> But it may not be practical unless the process goes as fast and painless >> as the grandfathering of commapi did. >> >> Another option may be the old kaffe extensions that moved to gnu >> classpathx. These don't have the native libraries but should provide >> the 2.0 interface and the javax.comm.properties mechansim for SPI. >> >> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From florianmanschwetus at gmx.de Tue Aug 5 05:04:46 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 13:04:46 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: References: <48971C1F.9020806@gmx.de> Message-ID: <489833CE.1040801@gmx.de> Just look at sendCommand in this method I have to place a Thread.sleep(20) after each byte send to get working. Even the event based receive doesn't work fine but this could be may stupidness. The specifikation document (it is on the last pages of the manual) for the beamer could be found on: http://www.optoma.co.uk/support.aspx Florian Manschwetus Trent Jarvi schrieb: > > Hi Florian > > Sorry for the top post in advance. I worry you may not see my answer > under all your code :) > > I have not received this email before. This is 500k of code which I > don't have time to read. I can spend about 5 min on each hobby email > and still get to work in the morning. I have a couple suggestions for > how to get an answer. > > First, cut out your comments and extra code so you can demonstrate the > question (I might even glance and see what is wrong then). Don't go for > a working final product. Isolate the problem using a simple program and > then ask with that as an example. If I did what you just did, I'd have > to post 3/4 of a million lines of code :) > > Second, join the rxtx mail-list and ask there. This will give you 100x > more eyes. I'll also read and try to follow. > > -- > taj > > > > On Mon, 4 Aug 2008, Florian Manschwetus wrote: > >> It could be that my university account is blocked by filters so >> resending from here. >> >> >> Topic is to control Optoma HD80 beamer using rs232 serial chat. >> This code is able to detect power state and switch the beamer on / off. >> connected is the beamer using a digitus usb 2.0 serial adapter with an >> FT232 USB-Serial adapter the systems architecture is amd64. >> >> Please take a look in the sendCommand routine i have to place theire >> those Thread.sleep to get it working. >> Now the question is this correct or is there a better way to get this >> working correctly? >> >> In the javadoc coming with the install i found this: >> setBaudBase >> >> public boolean setBaudBase(int BaudBase) >> throws UnsupportedCommOperationException, >> java.io.IOException >> >> Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 >> before using. >> >> could this explain the error? >> I attached my java source and the protocol description for the beamer >> (available on vendor website). >> >> thx, >> Florian Manschwetus >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: TestRS232.java Type: text/x-java Size: 9143 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0058.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0059.bin From michael.erskine at ketech.com Tue Aug 5 05:53:49 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Tue, 5 Aug 2008 12:53:49 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489833CE.1040801@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> > Just look at sendCommand in this method I have to place a > Thread.sleep(20) after each byte send to get working. Even the event > based receive doesn't work fine but this could be may stupidness. Hi Florian, Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. Regards, Michael Erskine. From florianmanschwetus at gmx.de Tue Aug 5 07:28:15 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:28:15 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> Message-ID: <4898556F.8000208@gmx.de> Michael Erskine schrieb: >> Just look at sendCommand in this method I have to place a >> Thread.sleep(20) after each byte send to get working. Even the event >> based receive doesn't work fine but this could be may stupidness. > > Hi Florian, > > Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. > > Regards, > Michael Erskine. > Ok, sounds fine for the receiving problem. But why i have to wait after each byte when sending a command squence? (the for loop in send command) Florian > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/284f350c/attachment-0028.bin From florianmanschwetus at gmx.de Tue Aug 5 07:44:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:44:14 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <4898592E.2020908@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >>> Just look at sendCommand in this method I have to place a >>> Thread.sleep(20) after each byte send to get working. Even the event >>> based receive doesn't work fine but this could be may stupidness. >> >> Hi Florian, >> >> Yes, naturally you'll have to wait for a response from the other end. >> Why not wait for notification from the event thread perhaps using a >> BlockingDeque rather than your LinkedList. Generally I >> try to decouple all input and output streams: in your case your >> application is operating synchronously like the "expect" program >> (http://expect.nist.gov/) so waits (or timeouts) will need to be >> factored in. >> >> Regards, >> Michael Erskine. >> > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) > > Florian Furthermore there is this basic baud with this confusing javadoc entry: public boolean setBaudBase(int BaudBase) throws UnsupportedCommOperationException, java.io.IOException Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 before using. maybe this could explain something Florian >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/006c7425/attachment-0028.bin From jredman at ergotech.com Tue Aug 5 09:13:36 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 05 Aug 2008 09:13:36 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: Message-ID: <48986E20.3060104@ergotech.com> Trent, So two issues: 1) Technically I'm still not sure how easy/practical a layer would be. The problems are always classes like listeners, and wrapping returns of gnu.io classes. I really see it as a "delegate" type of concept. Any thoughts or ideas of the practicality of this approach? The idea is not to modify RXTX. 2) Javax. The javax namespace does seem to be in widespread use outside of Sun (the same is true for the java namespace). The classpath extensions, or some other location, should be interested in a JavaComm implementation even if it does have dependencies on RXTX. Would you have any philosophical objection to an approach like that? Of course, I suspect it might be better if someone with that authority at Sun would admit that the javax namespace is already in the wild and that there is no problem with it being used within RXTX. Jim Trent Jarvi wrote: > Hi Jim, > > I will not step into the javax.comm namespace without Sun's explicite > permission. I fully understand the pain point you are trying to address. > > In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm > Linux) - which remains an integral part of rxtx. At the time it was a win for > Sun and rxtx. > > The Sun commapi license is/was fairly clear that rxtx should not step into that > namespace. It made sense as Sun was active in that space and rxtx may go into > another namespace - it was an experiment in working with Sun. > > This may sound silly looking at something that happened almost 10 years ago. > In a community of respect which Sun helped create, there is no question about > what to do. I hope eventually Sun will step up and do a right thing too. > > I agree that this is hurting the API more than helping it. There are also > questions about how to replace the API in the long term which includes HID > support which isn't going well so far. > > Others that can't even look at Sun's javax.comm today and can look at Kaffe's > contribution to classpathx can easily work around such restrictions. > > On Mon, 4 Aug 2008, Jim Redman wrote: > >> Has there been any work/would it be possible, to layer a javacomm >> look-alike on top of the GNU code? >> >> The goal is not to move the javax code forward, but to emulate the >> "legacy" javax packages for people who still need this. >> >> Jim >> >> Trent Jarvi wrote: >>> It would be nice to work with Sun to resolve those longstanding issues. >>> But it may not be practical unless the process goes as fast and painless >>> as the grandfathering of commapi did. >>> >>> Another option may be the old kaffe extensions that moved to gnu >>> classpathx. These don't have the native libraries but should provide >>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>> >>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From sandeep at genevasoftech.com Tue Aug 5 11:18:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Tue, 05 Aug 2008 22:48:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <48988B6C.5080409@genevasoftech.com> Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. *-- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/ad20f1cb/attachment-0028.html From Martin.Oberhuber at windriver.com Tue Aug 5 13:30:17 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Tue, 5 Aug 2008 21:30:17 +0200 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Sandeep, shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on Sol7 but I've successfully run it on Sol9 and Sol10. Or is your request really about a native 64bit variant? I'm afraid that then you're out of luck since I think that quite a bit of RXTX is not yet ready for 64 bit. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Sandeep Kumar K Sent: Tuesday, August 05, 2008 7:19 PM To: rxtx at qbang.org Subject: [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so for Solaris 9 Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. -- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/81b7f988/attachment-0028.html From tjarvi at qbang.org Tue Aug 5 22:38:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 22:38:34 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 5 Aug 2008, Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built > on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid that > then > you're out of luck since I think that quite a bit of RXTX is not yet > ready > for 64 bit. > While rxtx-2.1-7 probably has problems, The CVS code should be OK for 64 bit Solaris. If it isn't, let me know and I'll find which patch is missing. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Aug 5 23:13:00 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 23:13:00 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48986E20.3060104@ergotech.com> References: <48986E20.3060104@ergotech.com> Message-ID: On Tue, 5 Aug 2008, Jim Redman wrote: > Trent, > > So two issues: > > 1) Technically I'm still not sure how easy/practical a layer would be. The > problems are always classes like listeners, and wrapping returns of gnu.io > classes. I really see it as a "delegate" type of concept. Any thoughts or > ideas of the practicality of this approach? The idea is not to modify RXTX. I have not put too much thought into this. I assume you want what rxtx 2.0 provided to tie into javax.comm implementations. More classes could be added to rxtx 2.1-7 for SPI support. Maintaining rxtx-2.0 could also be handed to someone if they like. > > 2) Javax. The javax namespace does seem to be in widespread use outside of > Sun (the same is true for the java namespace). The classpath extensions, or > some other location, should be interested in a JavaComm implementation even > if it does have dependencies on RXTX. Would you have any philosophical > objection to an approach like that? > No problems. Classpathx would be a possible place to do it. I'd suggest thinking twice about what this involves in practical terms. You would be wanting to revive the 2.0 API while Sun is at 3.0 and grandfathering the JSR. This undermines the main reason (established api) for using the javax.comm namespace and does not leave such a project in a good position. The only win I see here is maintaining support for applications that can't migrate namespaces. Not that that isn't important. At some point it is going to be less work to just edit the bytecode :) Such a javax.comm effort would also be signing up new projects that decided to use the work up for concerns they probably will not understand or expect. That probably isn't a good path to facilitate for new projects at this time. We will put a good faith effort to work well with others but keep in mind the project has limited bandwidth for such efforts. > Of course, I suspect it might be better if someone with that authority at Sun > would admit that the javax namespace is already in the wild and that there is > no problem with it being used within RXTX. > > Jim > > Trent Jarvi wrote: >> Hi Jim, >> >> I will not step into the javax.comm namespace without Sun's explicite >> permission. I fully understand the pain point you are trying to address. >> >> In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java >> Comm Linux) - which remains an integral part of rxtx. At the time it was a >> win for Sun and rxtx. >> >> The Sun commapi license is/was fairly clear that rxtx should not step into >> that namespace. It made sense as Sun was active in that space and rxtx may >> go into another namespace - it was an experiment in working with Sun. >> >> This may sound silly looking at something that happened almost 10 years >> ago. In a community of respect which Sun helped create, there is no >> question about what to do. I hope eventually Sun will step up and do a >> right thing too. >> >> I agree that this is hurting the API more than helping it. There are also >> questions about how to replace the API in the long term which includes HID >> support which isn't going well so far. >> >> Others that can't even look at Sun's javax.comm today and can look at >> Kaffe's contribution to classpathx can easily work around such >> restrictions. >> >> On Mon, 4 Aug 2008, Jim Redman wrote: >> >>> Has there been any work/would it be possible, to layer a javacomm >>> look-alike on top of the GNU code? >>> >>> The goal is not to move the javax code forward, but to emulate the >>> "legacy" javax packages for people who still need this. >>> >>> Jim >>> >>> Trent Jarvi wrote: >>>> It would be nice to work with Sun to resolve those longstanding issues. >>>> But it may not be practical unless the process goes as fast and painless >>>> as the grandfathering of commapi did. >>>> >>>> Another option may be the old kaffe extensions that moved to gnu >>>> classpathx. These don't have the native libraries but should provide >>>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>>> >>>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From sandeep at genevasoftech.com Wed Aug 6 00:03:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Wed, 06 Aug 2008 11:33:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: <48993EB8.30107@genevasoftech.com> Thank you Mr. Martin for your suggestion. The native file which is given in rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am getting the following error . Any suggestions to solve this issue. I am using Solaris SPARC 64 bit machine. ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) thrown while loading gnu.io.RXTXCommDriver Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(Unknown Source) at java.lang.ClassLoader.loadLibrary(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) at com.ReadFromModem.main(ReadFromModem.java:84) * * *Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid > that then > you're out of luck since I think that quite a bit of RXTX is not yet ready > for 64 bit. > > Cheers, > -- > *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > ------------------------------------------------------------------------ > *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On > Behalf Of *Sandeep Kumar K > *Sent:* Tuesday, August 05, 2008 7:19 PM > *To:* rxtx at qbang.org > *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so > for Solaris 9 > > Hi, > > Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 > bit machine. The librxtxSerial.so given in website is for Solaris 8. > > *-- > > Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/1e920343/attachment-0028.html From tjarvi at qbang.org Wed Aug 6 00:21:42 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 00:21:42 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <48993EB8.30107@genevasoftech.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> <48993EB8.30107@genevasoftech.com> Message-ID: Hi Sandeep You may be out of luck unless you can compile the 2.1 src in CVS (requires gnu make and gcc). But you could try the ToyBox(R)(TM) which is a collection of WiLdLy untested cross compiled 2.1-7 binaries covering everything from the ibm z series to embeded arm/ppc. To give an idea how poorly these are tested, I don't even know if z series machines have a serial port. ftp://www.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Solaris They should at least match the binary types. Actually, I think if you use the rxtx jar from CVS with that file, it should 'work' as the fix for 64 bits was in java not the native code. You could just cd rxtx*/src; javac *.java then jar -cf RXTXcomm.jar `find -name \*.class` to create the hybrid which will complain about version information a bit. On Wed, 6 Aug 2008, Sandeep Kumar K wrote: > Thank you Mr. Martin for your suggestion. The native file which is given in > rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am > getting the following error . > Any suggestions to solve this issue. > I am using Solaris SPARC 64 bit machine. > > ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar > java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 > (Possible cause: architecture word > width mismatch) thrown while loading gnu.io.RXTXCommDriver > Exception in thread "main" java.lang.UnsatisfiedLinkError: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF > class: ELFCLASS64 (Possible cause: > architecture word width mismatch) > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(Unknown Source) > at java.lang.ClassLoader.loadLibrary(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > at com.ReadFromModem.main(ReadFromModem.java:84) > > * > * > > *Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > > > Oberhuber, Martin wrote: >> Sandeep, >> shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse >> variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on >> Sol7 but I've successfully run it on Sol9 and Sol10. >> Or is your request really about a native 64bit variant? I'm afraid that >> then >> you're out of luck since I think that quite a bit of RXTX is not yet ready >> for 64 bit. >> Cheers, >> -- >> *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> ------------------------------------------------------------------------ >> *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On >> Behalf Of *Sandeep Kumar K >> *Sent:* Tuesday, August 05, 2008 7:19 PM >> *To:* rxtx at qbang.org >> *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so >> for Solaris 9 >> >> Hi, >> >> Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 >> bit machine. The librxtxSerial.so given in website is for Solaris 8. >> >> *-- >> Thanks & Regards >> >> Sandeep Kumar K >> Sr. Software Engineer >> Geneva Software Technologies >> Whitefield, Bangalore >> Mob : 9880193454* >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> From michael.erskine at ketech.com Wed Aug 6 01:39:28 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 6 Aug 2008 08:39:28 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Florian Manschwetus wrote: > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) Hi Florian, I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. Regards, Michael Erskine. From florianmanschwetus at gmx.de Wed Aug 6 02:53:16 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 06 Aug 2008 10:53:16 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Message-ID: <4899667C.6010706@gmx.de> Michael Erskine schrieb: > Florian Manschwetus wrote: >> Ok, sounds fine for the receiving problem. >> But why i have to wait after each byte when sending a command squence? >> (the for loop in send command) > > Hi Florian, > I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. > > Regards, > Michael Erskine. > correct with a terminal on the other end it works, my idea was that this basic baud has some influence. Could some one explain what it is for? Florian > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/c2b4fa84/attachment-0028.bin From rick_knight at rlknight.com Wed Aug 6 13:01:07 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:01:07 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F4F3.3020707@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > I have an application (Readerware) that uses RXTX with Javax to access the serial port. This used to work fine under previous Linux' and Java, but something has changed, I assume with Java itself , that is causing the application to fail with a link error. The application is not able to find librxtxSerialParallel.so. RXTX supplies librxtxSerial.so and librxtxParallel.so, but not librxtxSerialParallel.so. Where can I get librxtxSerialParallel.so, or do I need it? Is something else causing the lib to not be found? Thanks, Rick Knight From rick_knight at rlknight.com Wed Aug 6 13:17:55 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:17:55 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F8E3.5060400@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Thanks for the reply. The developer of the app I'm trying to use (Readerware) has sent me a copy of the comm.api and I've copied the library (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar into the proper places. When I try to run the application, I get this error... Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: /usr/lib/libSolarisSerialParallel.so: /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not little-endian (Possible cause: endianness mismatch) Caught java.lang.UnsatisfiedLinkError: com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I while loading driver com.sun.comm.SolarisDriver Is there a way around this error? Thanks again, Rick Knight From jlar310 at gmail.com Wed Aug 6 13:37:42 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 14:37:42 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899F8E3.5060400@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > The developer of the app I'm trying to use (Readerware) has sent me a > copy of the comm.api and I've copied the library > (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar > into the proper places. When I try to run the application, I get this > error... > > Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: > /usr/lib/libSolarisSerialParallel.so: > /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not > little-endian (Possible cause: endianness mismatch) > Caught java.lang.UnsatisfiedLinkError: > com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I > > while loading driver com.sun.comm.SolarisDriver > > Is there a way around this error? What host OS are you running? From your original post it looks like 32 bit Linux. The libSolarisSerialParallel.so file is for Sun Solaris and will vary depending on the underlying hardware architecture as well. Sorry for the double post Rick, but I failed to send this to the list the first time... -- Jeff From rick_knight at rlknight.com Wed Aug 6 13:44:29 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:44:29 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: <4899FF1D.9030504@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > > >> The developer of the app I'm trying to use (Readerware) has sent me a >> copy of the comm.api and I've copied the library >> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >> into the proper places. When I try to run the application, I get this >> error... >> >> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >> /usr/lib/libSolarisSerialParallel.so: >> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >> little-endian (Possible cause: endianness mismatch) >> Caught java.lang.UnsatisfiedLinkError: >> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >> >> while loading driver com.sun.comm.SolarisDriver >> >> Is there a way around this error? >> > > What host OS are you running? From your original post it looks like 32 > bit Linux. > > The libSolarisSerialParallel.so file is for Sun Solaris and will vary > depending on the underlying hardware architecture as well. > > I'm running Kubuntu Linux (debian based). It's 32 bit. Rick Knight From jlar310 at gmail.com Wed Aug 6 15:33:23 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 16:33:23 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > I don't think Sun did binary libraries for Linux in the 2.0 version. Can someone with more historical experience than I confirm that? I recently tried to port a Comm API application from Solaris sparc to Linux x86 and likewise could not get my hands on the binary libraries. I eventually just re-wrote the code to use the gnu namespace packages and rxtx 2.1. What I don't understand is why your application vendor does not provide everything you need to run their software. FYI: I have librxtxParallel.so and librxtxSerial.so installed at JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is /usr/java/default which is actually a softlink to /usr/java/jre1.6.0_05. -- Jeff From defiantlew at yahoo.com.au Wed Aug 6 16:29:33 2008 From: defiantlew at yahoo.com.au (Lew L) Date: Thu, 7 Aug 2008 08:29:33 +1000 Subject: [Rxtx] Sun's Comm API Documentation References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> Message-ID: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> As a matter of interest is the Sun Comm API documentation available somewhere? I have tried the Sun site but it seems to have been removed. Unless I have missed the documentation for RXTX? I javadocced the RXTX source but information (to me) is minimal. Somewhere I got the impression that the Sun Comm API docs is, or was, compatible with RXTX, what is the best docs to use in conjuntion with RXTX and where may the be available? Cheers Lew From rick_knight at rlknight.com Wed Aug 6 17:18:33 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:18:33 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A3149.4050306@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff I'm not sure if I posted this here or not, but when I try to build RXTX from source I get this install error... make all-am make[1]: Entering directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' make[1]: Nothing to be done for `all-am'. make[1]: Leaving directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 Can you tell me how to get past this error and get RXTX built and installed? Thanks, Rick From bboyes at systronix.com Wed Aug 6 17:40:12 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Wed, 06 Aug 2008 17:40:12 -0600 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: At 16:29 08/06/2008, Lew L wrote: >As a matter of interest is the Sun Comm API documentation available >somewhere? I have tried the Sun site but it seems to have been removed. It's in the file we have posted, link in prev email (sorry, in a huge hurry right now). Javadocs definitely there. >Unless I have missed the documentation for RXTX? I javadocced the RXTX >source but information (to me) is minimal. >Somewhere I got the impression that the Sun Comm API docs is, or was, >compatible with RXTX, what is the best docs to use in conjuntion with RXTX >and where may the be available? Yeah, this is one of my concerns/beefs. There is little documentation for RXTX and it isn't just the same as javaxcomm. I would be willing to help out writing docs for RXTX! Yes really... esp if we can fix the Bluetooth issues. best regards Bruce >Cheers >Lew > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx ------- WWW.SYSTRONIX.COM ---------- Real embedded Java and much more +1-801-534-1017 Salt Lake City, USA From rick_knight at rlknight.com Wed Aug 6 17:54:08 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:54:08 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A39A0.2090309@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff, I would like for my vendor to switch to rxtx 2.1. It would make things much easier for me. I'm not sure why he's still using the javax compatible code. He's a small operation. Re-writing the code to use gnu namespace sounds like a major overhaul. Was it? Thanks, Rick From tjarvi at qbang.org Wed Aug 6 21:35:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:35:12 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: >> >>> Jeff wrote: >>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>>> >>>> >>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things > much easier for me. I'm not sure why he's still using the javax > compatible code. He's a small operation. Re-writing the code to use gnu > namespace sounds like a major overhaul. Was it? > Hi Jeff, The changes are fairly mechanical. Imports need to change and any explicite use of the namespace needs to change such as catching an exception. The following script was made for maintaining rxtx 2.0 but can apply to other needs. It is in the contrib dir with rxtx source. #!/bin/sh # Don't use! :) # # Sat, 03 May 2003 16:45:08 Modifications from J?rg Weule # Create a ed-cmd for the change of one pattern # case $1 in gnu) X=g/javax_comm/s+javax_comm+gnu_io+g ;; javax) X=g/gnu_io/s+gnu_io+javax_comm+g ;; *) echo;echo;echo From the top rxtx directory run;echo;echo -e \\t./ChangePackage.sh gnu;echo -e \\t\\tor;echo -e \\t./ChangePackage.sh javax;echo;echo; exit 0 ;; esac # # ed will be used to keep the owner and mode of the files unchanged. # We have run the ed-script for the characters '.' '/' as well. # "tr _ $D" do the change. # find . -type f -a -print | grep -v $0 | (while read F ; do ( echo $X; echo $X| tr _ /; echo $X| tr _ .; echo w; echo q ) | ed $F 2>&1 >/dev/null done ) # # Now we do little changes at the Makefiles. Hope that all we need. # find . -name Makefile\* -a -print | (while read F ; do cat < References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: On Thu, 7 Aug 2008, Lew L wrote: > As a matter of interest is the Sun Comm API documentation available > somewhere? I have tried the Sun site but it seems to have been removed. > > Unless I have missed the documentation for RXTX? I javadocced the RXTX > source but information (to me) is minimal. > Somewhere I got the impression that the Sun Comm API docs is, or was, > compatible with RXTX, what is the best docs to use in conjuntion with RXTX > and where may the be available? > Hi Lew, The documentation on Sun's website is accurate. The changes that are problematic in 3.0 are on the backside which rxtx used to plug into. http://java.sun.com/products/javacomm/reference/api/index.html CommPortIdentifier may have some minor differences (judging by the authors notes). -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Aug 6 21:46:08 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:46:08 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > If javax.comm.properties is properly installed and you are using a 2.0 version of Sun's commapi with rxtx 2.0, you should not see the library attempt to load libSolarisSerialParallel.so. Sun CommAPI 3.0 will not work with any version of rxtx as it is hard coded to use the shared library. See the INSTALL file with rxtx-2.0 source for more help with the properties file. -- Trent Jarvi tjarvi at qbang.org From jlar310 at gmail.com Thu Aug 7 06:32:06 2008 From: jlar310 at gmail.com (Jeff) Date: Thu, 7 Aug 2008 07:32:06 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > Jeff wrote: >> >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >> wrote: >> >>> >>> Jeff wrote: >>> >>>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>> wrote: >>>> >>>> >>>> >>>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things much > easier for me. I'm not sure why he's still using the javax compatible code. > He's a small operation. Re-writing the code to use gnu namespace sounds like > a major overhaul. Was it? I found it quite easy. In fact, in order to accommodate the transition, I actually separated all of the code that deals directly with the Comm API or RXTX into a helper class. The helper class was then coded to use reflection to determine which library was available and then instantiate the necessary objects. No direct imports of either library are used. The main application just needs to get it's hands on the IO streams and need not deal directly with the libraries. Other programs may not be so simple... But this doesn't really help you unless your vendor forks over the source code... -- Jeff From rick_knight at rlknight.com Thu Aug 7 09:47:12 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Thu, 07 Aug 2008 08:47:12 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: <489B1900.10108@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >>> wrote: >>> >>> >>>> Jeff wrote: >>>> >>>> >>>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>>> copy of the comm.api and I've copied the library >>>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>>> into the proper places. When I try to run the application, I get this >>>>>> error... >>>>>> >>>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>>> /usr/lib/libSolarisSerialParallel.so: >>>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>>> little-endian (Possible cause: endianness mismatch) >>>>>> Caught java.lang.UnsatisfiedLinkError: >>>>>> >>>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>>> >>>>>> while loading driver com.sun.comm.SolarisDriver >>>>>> >>>>>> Is there a way around this error? >>>>>> >>>>>> >>>>>> >>>>> What host OS are you running? From your original post it looks like 32 >>>>> bit Linux. >>>>> >>>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>>> depending on the underlying hardware architecture as well. >>>>> >>>>> >>>>> >>>>> >>>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>>> >>>> >>>> >>> I don't think Sun did binary libraries for Linux in the 2.0 version. >>> Can someone with more historical experience than I confirm that? >>> >>> I recently tried to port a Comm API application from Solaris sparc to >>> Linux x86 and likewise could not get my hands on the binary libraries. >>> I eventually just re-wrote the code to use the gnu namespace packages >>> and rxtx 2.1. >>> >>> What I don't understand is why your application vendor does not >>> provide everything you need to run their software. >>> >>> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >>> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >>> /usr/java/default which is actually a softlink to >>> /usr/java/jre1.6.0_05. >>> >>> >>> >> Jeff, >> >> I would like for my vendor to switch to rxtx 2.1. It would make things much >> easier for me. I'm not sure why he's still using the javax compatible code. >> He's a small operation. Re-writing the code to use gnu namespace sounds like >> a major overhaul. Was it? >> > > I found it quite easy. In fact, in order to accommodate the > transition, I actually separated all of the code that deals directly > with the Comm API or RXTX into a helper class. The helper class was > then coded to use reflection to determine which library was available > and then instantiate the necessary objects. No direct imports of > either library are used. The main application just needs to get it's > hands on the IO streams and need not deal directly with the libraries. > Other programs may not be so simple... > > But this doesn't really help you unless your vendor forks over the > source code... > > Jeff, This may not help me directly, but I'm going to forward this thread to the vendor. I think he'll be open to making things work. Thanks again, Rick Knight From agusmunioz at gmail.com Thu Aug 7 16:39:51 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Thu, 7 Aug 2008 19:39:51 -0300 Subject: [Rxtx] How to send ack? Message-ID: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Hi, I'm still learning about serial communication and I have some doubts. I've got this question about how to do the following thing in rxtx. I have this hardware that connect to a PC using a serial port. These hardware receives data from a telephone line, proccess it, and then send it forward to the serial port. I've used a program named wincomm that shows what information is send it through the serial port and I have the nex behaviour: The hardware has a buffer where all data is stored, that cannot be sent it through the seria port. The program reads the first data send it by the hardware, and keep reading the same data always. There is a button in the application that says enable Ack, and when I click, then the hardware start to send all the stored information, and all the information is shown. I write a class, using rxtx that reads the serial port, and the same thing happens, it remains reading the same (first) data all the time. And I thing something like the enable Ack I'm missing. How can I do this enable Ack from my java code using rxtx? Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080807/e0a0f9a1/attachment-0026.html From ajmas at sympatico.ca Thu Aug 7 18:26:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 7 Aug 2008 20:26:41 -0400 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: <4BF42297-81E2-4BB8-A89F-1D43588379AE@sympatico.ca> On 6-Aug-08, at 19:40 , Bruce Boyes wrote: >> Unless I have missed the documentation for RXTX? I javadocced the >> RXTX >> source but information (to me) is minimal. >> Somewhere I got the impression that the Sun Comm API docs is, or was, >> compatible with RXTX, what is the best docs to use in conjuntion >> with RXTX >> and where may the be available? > > Yeah, this is one of my concerns/beefs. There is little documentation > for RXTX and it isn't just the same as javaxcomm. > > I would be willing to help out writing docs for RXTX! Yes really... > esp if we can fix the Bluetooth issues. If you want to contribute documentation then the best place to do that is the wiki. If there is anything missing or that could be improved on then please do so. If there are any points that you would like to see improved, for which you don't have the knowledge then ask on the mailing list for a volunteer. Andre From florianmanschwetus at gmx.de Fri Aug 8 03:04:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Fri, 08 Aug 2008 11:04:14 +0200 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Message-ID: <489C0C0E.2020401@gmx.de> Agustin Mu?oz schrieb: > Hi, I'm still learning about serial communication and I have some > doubts. I've got this question about how to do the following thing in rxtx. > I have this hardware that connect to a PC using a serial port. These > hardware receives data from a telephone line, proccess it, and then send > it forward to the serial port. I've used a program named wincomm that > shows what information is send it through the serial port and I have the > nex behaviour: > > The hardware has a buffer where all data is stored, that cannot be sent > it through the seria port. > The program reads the first data send it by the hardware, and keep > reading the same data always. > There is a button in the application that says enable Ack, and when I > click, then the hardware start to send all the stored information, and > all the information is shown. > > I write a class, using rxtx that reads the serial port, and the same > thing happens, it remains reading the same (first) data all the time. > And I thing something like the enable Ack I'm missing. > How can I do this enable Ack from my java code using rxtx? Afaik, a look at man ascii reveals: Okt Dez Hex Char 006 6 06 ACK So, i hope this will do the job: send(6); florian > > Thanks in advance > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/5b4965f8/attachment-0026.bin From agusmunioz at gmail.com Fri Aug 8 16:31:00 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 19:31:00 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <489C0C0E.2020401@gmx.de> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> Message-ID: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Hi Florian, thanks for the answer. By send(6) you mean to get the port OutputStream and write a 6? I try that but it didn't work. Any suggestion? Thanks On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < florianmanschwetus at gmx.de> wrote: > Agustin Mu?oz schrieb: > > Hi, I'm still learning about serial communication and I have some doubts. >> I've got this question about how to do the following thing in rxtx. >> I have this hardware that connect to a PC using a serial port. These >> hardware receives data from a telephone line, proccess it, and then send it >> forward to the serial port. I've used a program named wincomm that shows >> what information is send it through the serial port and I have the nex >> behaviour: >> >> The hardware has a buffer where all data is stored, that cannot be sent >> it through the seria port. >> The program reads the first data send it by the hardware, and keep reading >> the same data always. >> There is a button in the application that says enable Ack, and when I >> click, then the hardware start to send all the stored information, and all >> the information is shown. >> >> I write a class, using rxtx that reads the serial port, and the same thing >> happens, it remains reading the same (first) data all the time. And I thing >> something like the enable Ack I'm missing. >> How can I do this enable Ack from my java code using rxtx? >> > Afaik, a look at man ascii reveals: > Okt Dez Hex Char > 006 6 06 ACK > So, i hope this will do the job: > send(6); > > florian > >> >> Thanks in advance >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/7f3fba42/attachment-0025.html From agusmunioz at gmail.com Fri Aug 8 18:39:27 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 21:39:27 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Message-ID: <988288430808081739x7f9e7889id82591d5a9e2b4f6@mail.gmail.com> Ok, Florian, it works!! my problem was that I've been sending, through the OutputStream, the bytes of 6 as a string: out.write("6".getBytes()); but then I realized that you can write an int on an OuptuStream, so I tried that and It works: out.write(6); Thank you for the guidance!! On Fri, Aug 8, 2008 at 7:31 PM, Agustin Mu?oz wrote: > Hi Florian, thanks for the answer. By send(6) you mean to get the port > OutputStream and write a 6? > > I try that but it didn't work. > > Any suggestion? > > Thanks > > > On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < > florianmanschwetus at gmx.de> wrote: > >> Agustin Mu?oz schrieb: >> >> Hi, I'm still learning about serial communication and I have some doubts. >>> I've got this question about how to do the following thing in rxtx. >>> I have this hardware that connect to a PC using a serial port. These >>> hardware receives data from a telephone line, proccess it, and then send it >>> forward to the serial port. I've used a program named wincomm that shows >>> what information is send it through the serial port and I have the nex >>> behaviour: >>> >>> The hardware has a buffer where all data is stored, that cannot be sent >>> it through the seria port. >>> The program reads the first data send it by the hardware, and keep >>> reading the same data always. >>> There is a button in the application that says enable Ack, and when I >>> click, then the hardware start to send all the stored information, and all >>> the information is shown. >>> >>> I write a class, using rxtx that reads the serial port, and the same >>> thing happens, it remains reading the same (first) data all the time. And I >>> thing something like the enable Ack I'm missing. >>> How can I do this enable Ack from my java code using rxtx? >>> >> Afaik, a look at man ascii reveals: >> Okt Dez Hex Char >> 006 6 06 ACK >> So, i hope this will do the job: >> send(6); >> >> florian >> >>> >>> Thanks in advance >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/b918ab3d/attachment-0025.html From florianmanschwetus at gmx.de Sat Aug 9 00:45:43 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Sat, 09 Aug 2008 08:45:43 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4899667C.6010706@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> Message-ID: <489D3D17.9090209@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >> Florian Manschwetus wrote: >>> Ok, sounds fine for the receiving problem. >>> But why i have to wait after each byte when sending a command squence? >>> (the for loop in send command) >> >> Hi Florian, >> I'd imagine you probably don't! You could send all bytes in one go and >> RXTX would send them. The problem is most probably the other end: >> perhaps it has a really small buffer, some non-standard UART, or a >> crazy timing issue. If you attach a terminal to your output and send >> all the bytes of a command in one go they should appear no problem. >> >> Regards, >> Michael Erskine. >> > correct with a terminal on the other end it works, my idea was that this > basic baud has some influence. Could some one explain what it is for? > > Florian To make it more clear, my problem is that i can't use: outputStream.write(byte[]); => Beamer doesn't understand the sequence. (mostly no answer when he answers then *001) when i use this construct instead: for (int i = 0; i < command.length; i++) { this.outputStream.write(command[i]); try { Thread.sleep(25); } catch (InterruptedException e) { // TODO Auto-generated catch block e.printStackTrace(); } } it works nearly reliable. So what could it be? This Basic Baud is what exactly? Florian -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080809/692304ee/attachment-0025.bin From tjarvi at qbang.org Sat Aug 9 16:37:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Aug 2008 16:37:19 -0600 (MDT) Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489D3D17.9090209@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> <489D3D17.9090209@gmx.de> Message-ID: On Sat, 9 Aug 2008, Florian Manschwetus wrote: > Florian Manschwetus schrieb: >> Michael Erskine schrieb: >>> Florian Manschwetus wrote: >>>> Ok, sounds fine for the receiving problem. >>>> But why i have to wait after each byte when sending a command squence? >>>> (the for loop in send command) >>> >>> Hi Florian, >>> I'd imagine you probably don't! You could send all bytes in one go and >>> RXTX would send them. The problem is most probably the other end: perhaps >>> it has a really small buffer, some non-standard UART, or a crazy timing >>> issue. If you attach a terminal to your output and send all the bytes of a >>> command in one go they should appear no problem. >>> >>> Regards, >>> Michael Erskine. >>> >> correct with a terminal on the other end it works, my idea was that this >> basic baud has some influence. Could some one explain what it is for? >> >> Florian > To make it more clear, > my problem is that i can't use: > outputStream.write(byte[]); > => Beamer doesn't understand the sequence. (mostly no answer when he answers > then *001) > > when i use this construct instead: > > for (int i = 0; i < command.length; i++) { > this.outputStream.write(command[i]); > try { > Thread.sleep(25); > } catch (InterruptedException e) { > // TODO Auto-generated catch block > e.printStackTrace(); > } > } > > it works nearly reliable. > > So what could it be? This Basic Baud is what exactly? > I suspect you are using the 'moon protocol' and don't know it. RXTX enables this by default. The buffer on the other end is first in first out while reading. If the buffer is full, the bits are hand carried to the moon and burried. Then if the other side reads a couple bytes, two more bytes go into the buffer followed by more moon protocol. The resulting array of bytes the other side reads may appear to be scrambled until you go to the moon, get the bits and insert them in the right place. Flow control can prevent the default moon protocol and throttles the communiation by almost writing a byte at a time as need be. Hardware flow control is preferable but software flow control should also work. Read and write can appear to hang if the other side is not connected. This is why we don't enable them all the time. If you can't use flow control, you have to take care with the moon protocol and give the other side time to read. That is what your slower version of write is doing. -- Trent Jarvi tjarvi at qbang.org From rxtx at allenjb.me.uk Mon Aug 11 08:06:36 2008 From: rxtx at allenjb.me.uk (AllenJB) Date: Mon, 11 Aug 2008 15:06:36 +0100 Subject: [Rxtx] Disabling EV_RXFLAG Message-ID: <48A0476C.2090800@allenjb.me.uk> Hi all, I'm working with a device which does not use an EvtChar and need to disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an event mask of FD 01 00 00. The reference software I have uses FB 00 00 00. With the rxtx mask I get framing errors which I believe are caused when the EvtChar is received. Is there currently a way with rxtx (I've using rxtx from Java) to disable EV_RXFLAG? If not from Java, where would I start if I wanted to turn the EV_RXFLAG option off in the C code? I've had a grep of the rxtx source code, but I can't see where EV_RXFLAG is being set. Thanks in advance, AllenJB From tjarvi at qbang.org Mon Aug 11 14:17:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Aug 2008 14:17:27 -0600 (MDT) Subject: [Rxtx] Disabling EV_RXFLAG In-Reply-To: <48A0476C.2090800@allenjb.me.uk> References: <48A0476C.2090800@allenjb.me.uk> Message-ID: On Mon, 11 Aug 2008, AllenJB wrote: > Hi all, > > I'm working with a device which does not use an EvtChar and need to > disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an > event mask of FD 01 00 00. The reference software I have uses FB 00 00 > 00. With the rxtx mask I get framing errors which I believe are caused > when the EvtChar is received. > > Is there currently a way with rxtx (I've using rxtx from Java) to > disable EV_RXFLAG? > > If not from Java, where would I start if I wanted to turn the EV_RXFLAG > option off in the C code? I've had a grep of the rxtx source code, but I > can't see where EV_RXFLAG is being set. > > Thanks in advance, > > AllenJB Hi Allen, I'd look at termios.c::tcsetattr() and termios.c::FillDCB() -- Trent Jarvi tjarvi at qbang.org From superdadusa at gmail.com Tue Aug 12 13:57:32 2008 From: superdadusa at gmail.com (John Choi) Date: Tue, 12 Aug 2008 13:57:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. Message-ID: Hi all, Just let you all know I just start to learn Java. I have download the serial comm package and the source code from open source communities.. I was able to verify with the given message string via serial monitor. when the given message string sends to the serial port then the character return added to the end of string by default if I use "Hello World" however if I changed to something else other than "Hello, World" there is no character return add to the end of string. I thing the library download from rxtx.org has implemented for the special strings. I can do like "login\n" in the string message to make character return but I don't want to add this individual custom character for each command return in every static message string I send, Can any who have done this might help me? Basically, something like this,, Write and add function to the program write a command, Reads the respond from a serial device.. Function handles multiple messages, Write: "com open" Read: Welcome to my world" expected Write: "admin" Read: Password?, expected Write: "admin" Read: you are successfully login terminal, expected. And I need to add a separate function handler handles a character return add to the each command above. If anyone can help this I can do the reset? Thank you in advance, John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0021.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SerialIO.java Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0021.pl From Steffen.DETTMER at ingenico.com Wed Aug 13 02:16:38 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 13 Aug 2008 10:16:38 +0200 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: References: Message-ID: <20080813081638.GA25412@elberon.bln.de.ingenico.com> * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > I can do like "login\n" in the string message to make character > return but I don't want to add this individual custom character > for each command return in every static message string I send, and why not?! > Can any who have done this might help me? what's about with writing a small wrapper function adding the carriage return? However, this would be slow, because either you call write two times (very bad) or the string needs to be copied, \n appended and written (since you are using Java Performance probably isn't so critical). Personally I would write `"login\n"' and `username + "\n"' etc., because since it is part of the command it should be part of the command definition string. > Basically, something like this,, Write and add function to the program write > a command, Reads the respond from a serial device.. correctly reading a `line' is more difficult. If you cannot make assumptions about timeouts and/or you need to have low delay, you need to read byte wise. If you need to save CPU resources you might need to add some buffering layer that you can read byte-wise but that is reading blockwise with some small timeout (lets say for serial lines something around byte transmission time times three or so). > /* > * To change this template, choose Tools | Templates > * and open the template in the editor. > */ :) > package joliba; > > /** > * > * @author root > */ :) > // derived from SUN's examples in the javax.comm package > import java.io.*; > import java.util.*; > //import javax.comm.*; // for SUN's serial/parallel port libraries > import gnu.io.*; // for rxtxSerial library > > public class SerialIO implements Runnable, SerialPortEventListener { > static CommPortIdentifier portId; > static CommPortIdentifier saveportId; > static Enumeration portList; > InputStream inputStream; > SerialPort serialPort; > Thread readThread; You need a thread for your synchronous RPC-style protocol? > static String messageString = "Hello, world!"; > static OutputStream outputStream; > static boolean outputBufferEmptyFlag = false; > > public static void main(String[] args) { > boolean portFound = false; > String defaultPort; > > // determine the name of the serial port on several operating systems > String osname = System.getProperty("os.name","").toLowerCase(); > if ( osname.startsWith("windows") ) { > // windows > defaultPort = "COM1"; > } else if (osname.startsWith("linux")) { > // linux > defaultPort = "/dev/ttyS0"; > } else if ( osname.startsWith("mac") ) { > // mac > defaultPort = "????"; > } else { > System.out.println("Sorry, your operating system is not supported"); > return; > } Is such a construction recommended? Isn't there some abstraction (like COM1 working on any platform)? [...] > try { > // activate the OUTPUT_BUFFER_EMPTY notifier > serialPort.notifyOnOutputEmpty(true); > } catch (Exception e) { > System.out.println("Error setting event notification"); > System.out.println(e.toString()); > System.exit(-1); > } I doubt that -1 is defined, probably some 127 or so would be the result, maybe better simply `throw e'? > public void writetoport() { > System.out.println("Writing \""+messageString+"\" to "+serialPort.getName()); > try { > // write string to serial port > outputStream.write(messageString.getBytes()); > } catch (IOException e) {} > } maybe something like /** * Writes the given output string and an additional carriage * return to the current outputStream. */ public void writeStringToPort( /** The output string (without CR). */ String output ) throws IOException { String outputLine = output + "\n"; outputStream.write(outputLine.getBytes()); } ? > > public SerialIO() { > // initalize serial port > try { > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > } catch (PortInUseException e) {} if the port is in use, you continue? Wonder that this works in Java, I would assume serialPort beeing uninitialized which AFAIK is an error in Java. > try { > inputStream = serialPort.getInputStream(); > } catch (IOException e) {} > > try { > serialPort.addEventListener(this); > } catch (TooManyListenersException e) {} > > // activate the DATA_AVAILABLE notifier > serialPort.notifyOnDataAvailable(true); > > try { > // set port parameters > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > } catch (UnsupportedCommOperationException e) {} > > // start the read thread > readThread = new Thread(this); > readThread.start(); > > } I think in all those exception cases you can abort, because it is unlikely that ignoring those errors allow a successful continuation, so in this case maybe it would be better to add a throw clause to the method. > public void run() { > // first thing in the thread, we initialize the write operation > initwritetoport(); > try { > while (true) { > // write string to port, the serialEvent will read it > writetoport(); > Thread.sleep(1000); > } > } catch (InterruptedException e) {} > } Does this make sense? Your `SimpleReadApp' writes one and the same string each second? > public void serialEvent(SerialPortEvent event) { > switch (event.getEventType()) { > case SerialPortEvent.BI: > case SerialPortEvent.OE: > case SerialPortEvent.FE: > case SerialPortEvent.PE: > case SerialPortEvent.CD: > case SerialPortEvent.CTS: > case SerialPortEvent.DSR: > case SerialPortEvent.RI: > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > break; > case SerialPortEvent.DATA_AVAILABLE: > // we get here if data has been received > byte[] readBuffer = new byte[20]; > try { > // read data > while (inputStream.available() > 0) { > int numBytes = inputStream.read(readBuffer); > } > // print data > String result = new String(readBuffer); > System.out.println("Read: "+result); > } catch (IOException e) {} I doubt that this is correct. I would assume you will get a 20 bytes result always, if more bytes would be available they would be printed in a second line but if less bytes are read I'd assume that the buffer/result contains zero bytes from implicite readBuffer contents initialisation (zero is no string terminator in Java AFAIK). > break; > } > } > } oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From florianmanschwetus at gmx.de Wed Aug 13 06:09:31 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 13 Aug 2008 14:09:31 +0200 Subject: [Rxtx] someone has seen such errors? Message-ID: <48A2CEFB.90007@gmx.de> I mean my communication mostly works, but it is far from perfect could this be the reason? Florian Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/949b9947/attachment-0021.bin From superdadusa at gmail.com Wed Aug 13 08:40:32 2008 From: superdadusa at gmail.com (John Choi) Date: Wed, 13 Aug 2008 08:40:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: <20080813081638.GA25412@elberon.bln.de.ingenico.com> References: <20080813081638.GA25412@elberon.bln.de.ingenico.com> Message-ID: Thank you so much Steffen and I will try that suggestion. John On 8/13/08, Steffen DETTMER wrote: > > * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > > I can do like "login\n" in the string message to make character > > return but I don't want to add this individual custom character > > for each command return in every static message string I send, > > and why not?! > > > Can any who have done this might help me? > > what's about with writing a small wrapper function adding the > carriage return? > However, this would be slow, because either you call write two > times (very bad) or the string needs to be copied, \n appended > and written (since you are using Java Performance probably isn't > so critical). > > Personally I would write `"login\n"' and `username + "\n"' etc., > because since it is part of the command it should be part of the > command definition string. > > > Basically, something like this,, Write and add function to the program > write > > a command, Reads the respond from a serial device.. > > correctly reading a `line' is more difficult. If you cannot make > assumptions about timeouts and/or you need to have low delay, you > need to read byte wise. If you need to save CPU resources you > might need to add some buffering layer that you can read > byte-wise but that is reading blockwise with some small timeout > (lets say for serial lines something around byte transmission > time times three or so). > > > /* > > * To change this template, choose Tools | Templates > > * and open the template in the editor. > > */ > > :) > > > package joliba; > > > > /** > > * > > * @author root > > */ > > :) > > > // derived from SUN's examples in the javax.comm package > > import java.io.*; > > import java.util.*; > > //import javax.comm.*; // for SUN's serial/parallel port libraries > > import gnu.io.*; // for rxtxSerial library > > > > public class SerialIO implements Runnable, SerialPortEventListener { > > static CommPortIdentifier portId; > > static CommPortIdentifier saveportId; > > static Enumeration portList; > > InputStream inputStream; > > SerialPort serialPort; > > Thread readThread; > > You need a thread for your synchronous RPC-style protocol? > > > static String messageString = "Hello, world!"; > > static OutputStream outputStream; > > static boolean outputBufferEmptyFlag = false; > > > > public static void main(String[] args) { > > boolean portFound = false; > > String defaultPort; > > > > // determine the name of the serial port on several operating > systems > > String osname = System.getProperty("os.name","").toLowerCase(); > > if ( osname.startsWith("windows") ) { > > // windows > > defaultPort = "COM1"; > > } else if (osname.startsWith("linux")) { > > // linux > > defaultPort = "/dev/ttyS0"; > > } else if ( osname.startsWith("mac") ) { > > // mac > > defaultPort = "????"; > > } else { > > System.out.println("Sorry, your operating system is not > supported"); > > return; > > } > > Is such a construction recommended? Isn't there some abstraction > (like COM1 working on any platform)? > > [...] > > try { > > // activate the OUTPUT_BUFFER_EMPTY notifier > > serialPort.notifyOnOutputEmpty(true); > > } catch (Exception e) { > > System.out.println("Error setting event notification"); > > System.out.println(e.toString()); > > System.exit(-1); > > } > > I doubt that -1 is defined, probably some 127 or so would be the > result, maybe better simply `throw e'? > > > public void writetoport() { > > System.out.println("Writing \""+messageString+"\" to > "+serialPort.getName()); > > try { > > // write string to serial port > > outputStream.write(messageString.getBytes()); > > } catch (IOException e) {} > > } > > maybe something like > > /** > * Writes the given output string and an additional carriage > * return to the current outputStream. > */ > public void > writeStringToPort( > /** The output string (without CR). */ > String output > ) throws IOException > { > String outputLine = output + "\n"; > outputStream.write(outputLine.getBytes()); > } > > ? > > > > > public SerialIO() { > > // initalize serial port > > try { > > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > > } catch (PortInUseException e) {} > > if the port is in use, you continue? Wonder that this works in > Java, I would assume serialPort beeing uninitialized which AFAIK > is an error in Java. > > > try { > > inputStream = serialPort.getInputStream(); > > } catch (IOException e) {} > > > > try { > > serialPort.addEventListener(this); > > } catch (TooManyListenersException e) {} > > > > // activate the DATA_AVAILABLE notifier > > serialPort.notifyOnDataAvailable(true); > > > > try { > > // set port parameters > > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > } catch (UnsupportedCommOperationException e) {} > > > > // start the read thread > > readThread = new Thread(this); > > readThread.start(); > > > > } > > I think in all those exception cases you can abort, because it is > unlikely that ignoring those errors allow a successful > continuation, so in this case maybe it would be better to add a > throw clause to the method. > > > public void run() { > > // first thing in the thread, we initialize the write operation > > initwritetoport(); > > try { > > while (true) { > > // write string to port, the serialEvent will read it > > writetoport(); > > Thread.sleep(1000); > > } > > } catch (InterruptedException e) {} > > } > > Does this make sense? Your `SimpleReadApp' writes one and the > same string each second? > > > public void serialEvent(SerialPortEvent event) { > > switch (event.getEventType()) { > > case SerialPortEvent.BI: > > case SerialPortEvent.OE: > > case SerialPortEvent.FE: > > case SerialPortEvent.PE: > > case SerialPortEvent.CD: > > case SerialPortEvent.CTS: > > case SerialPortEvent.DSR: > > case SerialPortEvent.RI: > > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > > break; > > case SerialPortEvent.DATA_AVAILABLE: > > // we get here if data has been received > > byte[] readBuffer = new byte[20]; > > try { > > // read data > > while (inputStream.available() > 0) { > > int numBytes = inputStream.read(readBuffer); > > } > > // print data > > String result = new String(readBuffer); > > System.out.println("Read: "+result); > > } catch (IOException e) {} > > I doubt that this is correct. I would assume you will get a 20 > bytes result always, if more bytes would be available they would > be printed in a second line but if less bytes are read I'd assume > that the buffer/result contains zero bytes from implicite > readBuffer contents initialisation (zero is no string terminator > in Java AFAIK). > > > break; > > } > > } > > } > > oki, > > Steffen > > About Ingenico Throughout the world businesses rely on Ingenico for secure > and expedient electronic transaction acceptance. Ingenico products leverage > proven technology, established standards and unparalleled ergonomics to > provide optimal reliability, versatility and usability. This comprehensive > range of products is complemented by a global array of services and > partnerships, enabling businesses in a number of vertical sectors to accept > transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged > information. If you are not the addressee or authorized to receive this for > the addressee, you must not use, copy, disclose or take any action based on > this message or any information herein. If you have received this message in > error, please advise the sender immediately by reply e-mail and delete this > message. Thank you for your cooperation. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/73c4135c/attachment-0020.html From ajmas at sympatico.ca Sat Aug 16 07:15:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 09:15:41 -0400 Subject: [Rxtx] someone has seen such errors? In-Reply-To: <48A2CEFB.90007@gmx.de> References: <48A2CEFB.90007@gmx.de> Message-ID: <43B5E8DA-1D93-4D90-809B-AAF35FF724C5@sympatico.ca> On 13-Aug-08, at 08:09 , Florian Manschwetus wrote: > I mean my communication mostly works, but it is far from perfect > could this be the reason? > > Florian > > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control Judging by the error messages this looks related to the driver you are using. Do a search for the following string with you favourite search engine, it should turn up a few hits: ftdi_set_termios FAILED to set databits/stopbits/parity Andre From ajmas at sympatico.ca Sat Aug 16 19:12:04 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 21:12:04 -0400 Subject: [Rxtx] Using SerialPortEvent? Message-ID: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Hi, Could someone tell me how I should be using the SerialPortEvent? Am I meant to be waiting for data and then simply reading from the inputstream? If this is the case why no just block on an inputstream read? Andr? From tjarvi at qbang.org Sat Aug 16 19:41:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 16 Aug 2008 19:41:13 -0600 (MDT) Subject: [Rxtx] Using SerialPortEvent? In-Reply-To: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> References: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Message-ID: On Sat, 16 Aug 2008, Andre-John Mas wrote: > Hi, > > Could someone tell me how I should be using the SerialPortEvent? Am I > meant to be waiting for data and then simply reading from the > inputstream? If this is the case why no just block on an inputstream > read? > Polling for data is fine also. It really depends upon what you are trying to do. For instance, if you require x bytes before reading, you can start polling after data is available. If you read on the same thread as your GUI and are waiting for data in a read, the results may be less than desirable. Java programming is 'usually' event driven rather than polling based. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sat Aug 16 20:10:39 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 22:10:39 -0400 Subject: [Rxtx] Using SerialPortEvent? In-Reply-To: References: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Message-ID: <3E495D4C-BB28-4845-A6AB-984C9A826BDF@sympatico.ca> On 16-Aug-08, at 21:41 , Trent Jarvi wrote: > On Sat, 16 Aug 2008, Andre-John Mas wrote: > >> Hi, >> >> Could someone tell me how I should be using the SerialPortEvent? Am I >> meant to be waiting for data and then simply reading from the >> inputstream? If this is the case why no just block on an inputstream >> read? >> > > Polling for data is fine also. It really depends upon what you are > trying to do. For instance, if you require x bytes before reading, > you can start polling after data is available. If you read on the > same thread as your GUI and are waiting for data in a read, the > results may be less than desirable. > > Java programming is 'usually' event driven rather than polling based. Sounds good. I thought I would use this opportunity to provide a event based version of the TwoWaySerialComm example. Could you just validate it before I add it to the Wiki: package ajmas74.experimental; import gnu.io.CommPort; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; import gnu.io.SerialPortEvent; import gnu.io.SerialPortEventListener; import java.io.IOException; import java.io.InputStream; import java.io.OutputStream; /** * This version of the TwoWaySerialComm example makes use of the * SerialPortEventListener to avoid polling. * * @author ajmas * */ public class TwoWaySerialComm { public TwoWaySerialComm() { super(); } void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { CommPort commPort = portIdentifier.open(this.getClass().getName(),2000); if ( commPort instanceof SerialPort ) { SerialPort serialPort = (SerialPort) commPort; serialPort .setSerialPortParams (57600 ,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); (new Thread(new SerialWriter(out))).start(); serialPort.addEventListener(new SerialReader(in)); } else { System.out.println("Error: Only serial ports are handled by this example."); } } } /** * Handles the input coming from the serial port. A new line character * is treated as the end of a block in this example. */ public static class SerialReader implements SerialPortEventListener { private InputStream in; private byte[] buffer = new byte[1024]; public SerialReader ( InputStream in ) { this.in = in; } public void serialEvent(SerialPortEvent arg0) { int data; try { int len = 0; while ( ( data = in.read()) > -1 ) { if ( data != '\n' ) { break; } buffer[len++] = (byte) data; } System.out.print(new String(buffer,0,len)); } catch ( IOException e ) { e.printStackTrace(); System.exit(-1); } } } /** */ public static class SerialWriter implements Runnable { OutputStream out; public SerialWriter ( OutputStream out ) { this.out = out; } public void run () { try { int c = 0; while ( ( c = System.in.read()) > -1 ) { this.out.write(c); } } catch ( IOException e ) { e.printStackTrace(); System.exit(-1); } } } public static void main ( String[] args ) { try { (new TwoWaySerialComm()).connect("COM3"); } catch ( Exception e ) { e.printStackTrace(); } } } From lfarkas at lfarkas.org Tue Aug 19 07:32:59 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Tue, 19 Aug 2008 15:32:59 +0200 Subject: [Rxtx] JNI or CNI Message-ID: <48AACB8B.9060606@lfarkas.org> hi, what is the current recommended way to rxtx on linux JNI or it's better to use CNI? is the CNI version fully functional and the same level as the JNI? i currently try to make a rhel/centos/fedora rpm for rxtx but has many problems with the standard dir structure. yours. -- Levente "Si vis pacem para bellum!" From lfarkas at lfarkas.org Tue Aug 19 08:47:34 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Tue, 19 Aug 2008 16:47:34 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel Message-ID: <48AADD06.7040809@lfarkas.org> hi, newer or not so newer linux kernel do not contain the UTS_RELEASE so the current rxtx is not compile on the latest kernels. even if it's commented out in the cvs configure there are other places. i attcahed a patch which fix it (or at least doesn't cause error at non-debug build). ps. is there any plan to the new 2.1-8 release in the near future? there are many changes (at least the license change in all file and in this case create a diff is very difficult)? the latest release more then 2 years old:-( -- Levente "Si vis pacem para bellum!" -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-2.1-uts.patch Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080819/ab5d38ac/attachment-0014.pl From ajmas at sympatico.ca Tue Aug 19 16:21:53 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 19 Aug 2008 18:21:53 -0400 Subject: [Rxtx] Event based example Message-ID: <24735BFB-B088-4B84-8173-FE98DF63B12F@sympatico.ca> Hi, I have just posted an example of using SerialPortEventListener in the Wiki: http://rxtx.qbang.org/wiki/index.php/Event_Based_Two_Way_Communication If you see any issues please could you let me know, or makes the changes. Andre From Martin.Oberhuber at windriver.com Fri Aug 22 04:02:24 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 22 Aug 2008 12:02:24 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <48AADD06.7040809@lfarkas.org> References: <48AADD06.7040809@lfarkas.org> Message-ID: <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> Farkas, there are indeed efforts to get a new RXTX release out the door. Your experience as a package maintainer would likely be helpful during these efforts, since I'd think it makes sense to keep the patches minimal that you must make to have the source compile in your environment. What are the things that you find problematic, apart from the UTS thing that you have mentioned before? What is the timing that you have in mind for your package? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Farkas Levente > Sent: Tuesday, August 19, 2008 4:48 PM > To: rxtx at qbang.org > Subject: [Rxtx] UTS_RELEASE not defined in newer kernel > > hi, > newer or not so newer linux kernel do not contain the > UTS_RELEASE so the > current rxtx is not compile on the latest kernels. even if it's > commented out in the cvs configure there are other places. > i attcahed a patch which fix it (or at least doesn't cause error at > non-debug build). > > ps. is there any plan to the new 2.1-8 release in the near > future? there > are many changes (at least the license change in all file and in this > case create a diff is very difficult)? the latest release more then 2 > years old:-( > > -- > Levente "Si vis pacem para bellum!" > From lfarkas at lfarkas.org Fri Aug 22 04:36:26 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Fri, 22 Aug 2008 12:36:26 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> References: <48AADD06.7040809@lfarkas.org> <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> Message-ID: <48AE96AA.6090505@lfarkas.org> hi, the packages already build for fedora-9 and centos-5 and here: http://www.lfarkas.org/linux/packages/ what i've to patch, the UTS, the configure script, but it's already fixed in the cvs (in another way) and the loadlibrary. the reasons for last one can be found here: https://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_files_that_use_JNI after we test it i'd like to add these packages to fedora and epel main repository (that's why it's be useful a new release after 2 years:-) imho versions are cheap and why not just release 2.1-8? the real code changes are minimal and if something critical bug found still can release 2.1-9:-) ps. and would be better to use simple number for version like 2.1-7 rather then 2.1-7v2. Oberhuber, Martin wrote: > Farkas, > > there are indeed efforts to get a new RXTX release out the > door. Your experience as a package maintainer would likely > be helpful during these efforts, since I'd think it makes > sense to keep the patches minimal that you must make to > have the source compile in your environment. > > What are the things that you find problematic, apart from > the UTS thing that you have mentioned before? > > What is the timing that you have in mind for your package? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >> On Behalf Of Farkas Levente >> Sent: Tuesday, August 19, 2008 4:48 PM >> To: rxtx at qbang.org >> Subject: [Rxtx] UTS_RELEASE not defined in newer kernel >> >> hi, >> newer or not so newer linux kernel do not contain the >> UTS_RELEASE so the >> current rxtx is not compile on the latest kernels. even if it's >> commented out in the cvs configure there are other places. >> i attcahed a patch which fix it (or at least doesn't cause error at >> non-debug build). >> >> ps. is there any plan to the new 2.1-8 release in the near >> future? there >> are many changes (at least the license change in all file and in this >> case create a diff is very difficult)? the latest release more then 2 >> years old:-( >> >> -- >> Levente "Si vis pacem para bellum!" >> -- Levente "Si vis pacem para bellum!" From tjarvi at qbang.org Fri Aug 22 18:50:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Aug 2008 18:50:32 -0600 (MDT) Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <48AE96AA.6090505@lfarkas.org> References: <48AADD06.7040809@lfarkas.org> <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> <48AE96AA.6090505@lfarkas.org> Message-ID: Hi Farkas, The v2 was simply the second build - no code changes. We are comming out with a new release shortly. I would encourage working with distros as you are. The building of rxtx turns out to be a bottle neck in quick releases. We do want stable releases that work for a year or more but I would have no problems with quicker cycles on developing work. I would have no problem working with someone that did builds that receive less testing more often but they do have to come out for multiple platforms from this end. Thanks for the links. On Fri, 22 Aug 2008, Farkas Levente wrote: > hi, > the packages already build for fedora-9 and centos-5 and here: > http://www.lfarkas.org/linux/packages/ > what i've to patch, the UTS, the configure script, but it's already > fixed in the cvs (in another way) and the loadlibrary. the reasons for > last one can be found here: > https://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_files_that_use_JNI > after we test it i'd like to add these packages to fedora and epel main > repository (that's why it's be useful a new release after 2 years:-) > imho versions are cheap and why not just release 2.1-8? the real code > changes are minimal and if something critical bug found still can > release 2.1-9:-) > > ps. and would be better to use simple number for version like 2.1-7 > rather then 2.1-7v2. > > Oberhuber, Martin wrote: >> Farkas, >> >> there are indeed efforts to get a new RXTX release out the >> door. Your experience as a package maintainer would likely >> be helpful during these efforts, since I'd think it makes >> sense to keep the patches minimal that you must make to >> have the source compile in your environment. >> >> What are the things that you find problematic, apart from >> the UTS thing that you have mentioned before? >> >> What is the timing that you have in mind for your package? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >>> On Behalf Of Farkas Levente >>> Sent: Tuesday, August 19, 2008 4:48 PM >>> To: rxtx at qbang.org >>> Subject: [Rxtx] UTS_RELEASE not defined in newer kernel >>> >>> hi, >>> newer or not so newer linux kernel do not contain the >>> UTS_RELEASE so the >>> current rxtx is not compile on the latest kernels. even if it's >>> commented out in the cvs configure there are other places. >>> i attcahed a patch which fix it (or at least doesn't cause error at >>> non-debug build). >>> >>> ps. is there any plan to the new 2.1-8 release in the near >>> future? there >>> are many changes (at least the license change in all file and in this >>> case create a diff is very difficult)? the latest release more then 2 >>> years old:-( >>> >>> -- >>> Levente "Si vis pacem para bellum!" >>> > > > From andy at triera.net Sat Aug 23 15:17:44 2008 From: andy at triera.net (Andy Rozman) Date: Sat, 23 Aug 2008 21:17:44 +0000 Subject: [Rxtx] port not identified on FreeBSD In-Reply-To: References: Message-ID: <48B07E78.2030306@triera.net> Hi ! I have one small problem... I have started using FreeBSD in last few days and I have come accross a problem with rxtx on FreeBSD. I am using usb-to-serial converter, which is identified under FreeBSD without problem as ucom0, and creates link under /dev called ttyU0, which is correct way to be done under FreeBSD (if device would be unidentified it would be called ugen0 - as usb generic). Problem is that I say to rxtx to get my all serial ports this one is not among them. Which names are permissable under linux-like implementations? Which will be accepted as serial ports? Andy From tjarvi at qbang.org Sat Aug 23 13:57:45 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 23 Aug 2008 13:57:45 -0600 (MDT) Subject: [Rxtx] port not identified on FreeBSD In-Reply-To: <48B07E78.2030306@triera.net> References: <48B07E78.2030306@triera.net> Message-ID: On Sat, 23 Aug 2008, Andy Rozman wrote: > Hi ! > > I have one small problem... I have started using FreeBSD in last few > days and I have come accross a problem with rxtx on FreeBSD. > > I am using usb-to-serial converter, which is identified under FreeBSD > without problem as ucom0, and creates link under /dev called > ttyU0, which is correct way to be done under FreeBSD (if device would be > unidentified it would be called ugen0 - as usb generic). Problem is that > I say to rxtx to get my all serial ports this one is not among them. > Which names are permissable under linux-like implementations? Which will > be accepted as serial ports? > > Andy > Thanks Andy! We will add ttyU* to FreeBSD. For now you can use properties to enable the port. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting#How_does_rxtx_detect_ports.3F__Can_I_override_it.3F The fix: diff -u -r1.16.2.59 RXTXCommDriver.java --- RXTXCommDriver.java 18 Nov 2007 22:32:41 -0000 1.16.2.59 +++ RXTXCommDriver.java 23 Aug 2008 19:55:25 -0000 @@ -644,6 +644,7 @@ { String[] Temp = { "ttyd", //general purpose serial ports + "ttyU", //general purpose USB serial ports "cuaa", //dialout serial ports "ttyA", //Specialix SI/XIO dialin ports "cuaA", //Specialix SI/XIO dialout ports -- Trent Jarvi tjarvi at qbang.org From rick_knight at rlknight.com Mon Aug 4 13:25:10 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Mon, 04 Aug 2008 12:25:10 -0700 Subject: [Rxtx] Sun's Comm API? Message-ID: <48975796.4010600@rlknight.com> I have an application that requires the javax compatible version of RXTX and Sun's comm api. I've been able to download and extract the version of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api anywhere. Can someone tell me where I can find it? Or maybe send me a copy? Also, when I try to build RXTX, configure and make complete successfully but make install failes with this error libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 I've never come accross this error before. How can I get past it? Thanks, Rick From bboyes at systronix.com Mon Aug 4 19:10:01 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:10:01 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48975796.4010600@rlknight.com> References: <48975796.4010600@rlknight.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/cb9c6167/attachment-0030.html From bboyes at systronix.com Mon Aug 4 19:12:37 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:12:37 -0600 Subject: [Rxtx] Towards an RXTX release - CSR BT/USB chipset In-Reply-To: <488FB7E7.8000802@gmail.com> References: <460801A4097E3D4CA04CC64EE648584806C56CF0@ism-mail03.corp.ad.wrs.com> <13557-75390@sneakemail.com> <20980-23424@sneakemail.com> <488FB7E7.8000802@gmail.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/52236088/attachment-0030.html From tjarvi at qbang.org Mon Aug 4 19:42:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 19:42:21 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: On Mon, 4 Aug 2008, Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: > I have an application that requires the javax compatible > version of RXTX > and Sun's comm api. I've been able to download and extract > the version > of RXTX that I need (2.0-7pre2) but I can't find Sun's camm > api > anywhere. Can someone tell me where I can find it? Or maybe > send me a > > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm port > support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have just > a ZIP with only the .class JAR file - no source or docs), has a readme > with these comments: > > This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release.? The 2.0.3 release itself is > no longer distributed.? comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project.? The RxTx project (http://www.rxtx.org ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org) was opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support.? Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins.? Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > ? > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > I hope that is helpful! > It would be nice to work with Sun to resolve those longstanding issues. But it may not be practical unless the process goes as fast and painless as the grandfathering of commapi did. Another option may be the old kaffe extensions that moved to gnu classpathx. These don't have the native libraries but should provide the 2.0 interface and the javax.comm.properties mechansim for SPI. http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Mon Aug 4 20:23:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Mon, 04 Aug 2008 20:23:57 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4897B9BD.5070809@ergotech.com> Has there been any work/would it be possible, to layer a javacomm look-alike on top of the GNU code? The goal is not to move the javax code forward, but to emulate the "legacy" javax packages for people who still need this. Jim Trent Jarvi wrote: > On Mon, 4 Aug 2008, Bruce Boyes wrote: > >> At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible >> version of RXTX >> and Sun's comm api. I've been able to download and extract >> the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm >> api >> anywhere. Can someone tell me where I can find it? Or maybe >> send me a >> >> >> javaxcomm has had a sort of on-again off-again history. The windoze >> version has been languishing for years (literally) but there are newer >> versions for other OS's. >> >> We try to keep links on one of our help pages current: >> http://www.practicalembeddedjava.com/tools/javatools_list.html >> which gets you to here: >> http://java.sun.com/products/javacomm/ >> where it says in fact they no longer even support Windows and Mac: >> "Implementations of the API are currently available for Solaris SPARC, >> Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so >> someone could support it. But I guess that's part of the reason RXTX >> exists! >> >> So one of Sun's own products, SunSPOT, has to use RXTX to get comm port >> support. >> >> The version we use is 2.0 from 11/15/1998. I have posted it on our >> website, which is within the terms of the license agreement contained >> therein (as I understand it). >> >> The last version of javaxcomm for Windows, 2.0.3, (for which I have just >> a ZIP with only the .class JAR file - no source or docs), has a readme >> with these comments: >> >> This distribution contains the comm.jar file original part >> of the COMMAPI 2.0.3 release. The 2.0.3 release itself is >> no longer distributed. comm.jar, which contains the comm >> API java class files (eg. Sun's binary implementation of the >> interface classes), is being made available, unsupported, >> with no obligation to fix bugs, at the request of the RXTX >> project. The RxTx project (http://www.rxtx.org ), uses the >> comm.jar class files, but provides their own native library >> components to provide support for other platforms. >> >> The 2.0.3 comm.jar is being provided in this way because >> as of COMMAPI 3.x, the java binary implementation forked and >> became incompatible with the RxTx project's native code. >> Due to the lack of a clear business case, and to resource >> constraints, no additional resources are being >> provided to provide an alternative engineering solution >> at the time of writing. >> >> RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: >> >> Ultimately the COMMAPI would be better served if a Java >> Community Process JSR (http://www.jcp.org) was opened and >> the COMMAPI was rearchitected to provide a more pluggable >> framework to improve cross-platform support. Such an >> architecture would embody a better defined and better >> documented SPI interface, including a way for comm. ports >> to be revealed to the client application through the API >> via platform-aware plugins. Similarly, native code used >> to access comm port in general could be handled more >> flexibly using a plugin model, whereby on any platform, >> multiple native modules could be in use simultaneously. >> >> Since there are now various ways serial ports can be implemented >> and accessed, modular comm. port JNI native libraries would be >> of benefit insofar as removing the burden of over-generalization >> from any single native component, or inversely, by relieving the >> implicit constraint that comm. drivers be accessed only via a >> monolithic mechanism, such as the UNIX vnode interface. >> >> paul.klissner at sun.com >> 6/10/06 >> >> I hope that is helpful! >> > > It would be nice to work with Sun to resolve those longstanding issues. > But it may not be practical unless the process goes as fast and painless > as the grandfathering of commapi did. > > Another option may be the old kaffe extensions that moved to gnu > classpathx. These don't have the native libraries but should provide > the 2.0 interface and the javax.comm.properties mechansim for SPI. > > http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Mon Aug 4 21:09:15 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 21:09:15 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? Message-ID: Hi Jim, I will not step into the javax.comm namespace without Sun's explicite permission. I fully understand the pain point you are trying to address. In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm Linux) - which remains an integral part of rxtx. At the time it was a win for Sun and rxtx. The Sun commapi license is/was fairly clear that rxtx should not step into that namespace. It made sense as Sun was active in that space and rxtx may go into another namespace - it was an experiment in working with Sun. This may sound silly looking at something that happened almost 10 years ago. In a community of respect which Sun helped create, there is no question about what to do. I hope eventually Sun will step up and do a right thing too. I agree that this is hurting the API more than helping it. There are also questions about how to replace the API in the long term which includes HID support which isn't going well so far. Others that can't even look at Sun's javax.comm today and can look at Kaffe's contribution to classpathx can easily work around such restrictions. On Mon, 4 Aug 2008, Jim Redman wrote: > Has there been any work/would it be possible, to layer a javacomm > look-alike on top of the GNU code? > > The goal is not to move the javax code forward, but to emulate the > "legacy" javax packages for people who still need this. > > Jim > > Trent Jarvi wrote: >> >> It would be nice to work with Sun to resolve those longstanding issues. >> But it may not be practical unless the process goes as fast and painless >> as the grandfathering of commapi did. >> >> Another option may be the old kaffe extensions that moved to gnu >> classpathx. These don't have the native libraries but should provide >> the 2.0 interface and the javax.comm.properties mechansim for SPI. >> >> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From florianmanschwetus at gmx.de Tue Aug 5 05:04:46 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 13:04:46 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: References: <48971C1F.9020806@gmx.de> Message-ID: <489833CE.1040801@gmx.de> Just look at sendCommand in this method I have to place a Thread.sleep(20) after each byte send to get working. Even the event based receive doesn't work fine but this could be may stupidness. The specifikation document (it is on the last pages of the manual) for the beamer could be found on: http://www.optoma.co.uk/support.aspx Florian Manschwetus Trent Jarvi schrieb: > > Hi Florian > > Sorry for the top post in advance. I worry you may not see my answer > under all your code :) > > I have not received this email before. This is 500k of code which I > don't have time to read. I can spend about 5 min on each hobby email > and still get to work in the morning. I have a couple suggestions for > how to get an answer. > > First, cut out your comments and extra code so you can demonstrate the > question (I might even glance and see what is wrong then). Don't go for > a working final product. Isolate the problem using a simple program and > then ask with that as an example. If I did what you just did, I'd have > to post 3/4 of a million lines of code :) > > Second, join the rxtx mail-list and ask there. This will give you 100x > more eyes. I'll also read and try to follow. > > -- > taj > > > > On Mon, 4 Aug 2008, Florian Manschwetus wrote: > >> It could be that my university account is blocked by filters so >> resending from here. >> >> >> Topic is to control Optoma HD80 beamer using rs232 serial chat. >> This code is able to detect power state and switch the beamer on / off. >> connected is the beamer using a digitus usb 2.0 serial adapter with an >> FT232 USB-Serial adapter the systems architecture is amd64. >> >> Please take a look in the sendCommand routine i have to place theire >> those Thread.sleep to get it working. >> Now the question is this correct or is there a better way to get this >> working correctly? >> >> In the javadoc coming with the install i found this: >> setBaudBase >> >> public boolean setBaudBase(int BaudBase) >> throws UnsupportedCommOperationException, >> java.io.IOException >> >> Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 >> before using. >> >> could this explain the error? >> I attached my java source and the protocol description for the beamer >> (available on vendor website). >> >> thx, >> Florian Manschwetus >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: TestRS232.java Type: text/x-java Size: 9143 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0060.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0061.bin From michael.erskine at ketech.com Tue Aug 5 05:53:49 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Tue, 5 Aug 2008 12:53:49 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489833CE.1040801@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> > Just look at sendCommand in this method I have to place a > Thread.sleep(20) after each byte send to get working. Even the event > based receive doesn't work fine but this could be may stupidness. Hi Florian, Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. Regards, Michael Erskine. From florianmanschwetus at gmx.de Tue Aug 5 07:28:15 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:28:15 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> Message-ID: <4898556F.8000208@gmx.de> Michael Erskine schrieb: >> Just look at sendCommand in this method I have to place a >> Thread.sleep(20) after each byte send to get working. Even the event >> based receive doesn't work fine but this could be may stupidness. > > Hi Florian, > > Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. > > Regards, > Michael Erskine. > Ok, sounds fine for the receiving problem. But why i have to wait after each byte when sending a command squence? (the for loop in send command) Florian > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/284f350c/attachment-0029.bin From florianmanschwetus at gmx.de Tue Aug 5 07:44:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:44:14 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <4898592E.2020908@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >>> Just look at sendCommand in this method I have to place a >>> Thread.sleep(20) after each byte send to get working. Even the event >>> based receive doesn't work fine but this could be may stupidness. >> >> Hi Florian, >> >> Yes, naturally you'll have to wait for a response from the other end. >> Why not wait for notification from the event thread perhaps using a >> BlockingDeque rather than your LinkedList. Generally I >> try to decouple all input and output streams: in your case your >> application is operating synchronously like the "expect" program >> (http://expect.nist.gov/) so waits (or timeouts) will need to be >> factored in. >> >> Regards, >> Michael Erskine. >> > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) > > Florian Furthermore there is this basic baud with this confusing javadoc entry: public boolean setBaudBase(int BaudBase) throws UnsupportedCommOperationException, java.io.IOException Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 before using. maybe this could explain something Florian >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/006c7425/attachment-0029.bin From jredman at ergotech.com Tue Aug 5 09:13:36 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 05 Aug 2008 09:13:36 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: Message-ID: <48986E20.3060104@ergotech.com> Trent, So two issues: 1) Technically I'm still not sure how easy/practical a layer would be. The problems are always classes like listeners, and wrapping returns of gnu.io classes. I really see it as a "delegate" type of concept. Any thoughts or ideas of the practicality of this approach? The idea is not to modify RXTX. 2) Javax. The javax namespace does seem to be in widespread use outside of Sun (the same is true for the java namespace). The classpath extensions, or some other location, should be interested in a JavaComm implementation even if it does have dependencies on RXTX. Would you have any philosophical objection to an approach like that? Of course, I suspect it might be better if someone with that authority at Sun would admit that the javax namespace is already in the wild and that there is no problem with it being used within RXTX. Jim Trent Jarvi wrote: > Hi Jim, > > I will not step into the javax.comm namespace without Sun's explicite > permission. I fully understand the pain point you are trying to address. > > In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm > Linux) - which remains an integral part of rxtx. At the time it was a win for > Sun and rxtx. > > The Sun commapi license is/was fairly clear that rxtx should not step into that > namespace. It made sense as Sun was active in that space and rxtx may go into > another namespace - it was an experiment in working with Sun. > > This may sound silly looking at something that happened almost 10 years ago. > In a community of respect which Sun helped create, there is no question about > what to do. I hope eventually Sun will step up and do a right thing too. > > I agree that this is hurting the API more than helping it. There are also > questions about how to replace the API in the long term which includes HID > support which isn't going well so far. > > Others that can't even look at Sun's javax.comm today and can look at Kaffe's > contribution to classpathx can easily work around such restrictions. > > On Mon, 4 Aug 2008, Jim Redman wrote: > >> Has there been any work/would it be possible, to layer a javacomm >> look-alike on top of the GNU code? >> >> The goal is not to move the javax code forward, but to emulate the >> "legacy" javax packages for people who still need this. >> >> Jim >> >> Trent Jarvi wrote: >>> It would be nice to work with Sun to resolve those longstanding issues. >>> But it may not be practical unless the process goes as fast and painless >>> as the grandfathering of commapi did. >>> >>> Another option may be the old kaffe extensions that moved to gnu >>> classpathx. These don't have the native libraries but should provide >>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>> >>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From sandeep at genevasoftech.com Tue Aug 5 11:18:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Tue, 05 Aug 2008 22:48:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <48988B6C.5080409@genevasoftech.com> Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. *-- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/ad20f1cb/attachment-0029.html From Martin.Oberhuber at windriver.com Tue Aug 5 13:30:17 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Tue, 5 Aug 2008 21:30:17 +0200 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Sandeep, shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on Sol7 but I've successfully run it on Sol9 and Sol10. Or is your request really about a native 64bit variant? I'm afraid that then you're out of luck since I think that quite a bit of RXTX is not yet ready for 64 bit. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Sandeep Kumar K Sent: Tuesday, August 05, 2008 7:19 PM To: rxtx at qbang.org Subject: [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so for Solaris 9 Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. -- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/81b7f988/attachment-0029.html From tjarvi at qbang.org Tue Aug 5 22:38:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 22:38:34 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 5 Aug 2008, Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built > on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid that > then > you're out of luck since I think that quite a bit of RXTX is not yet > ready > for 64 bit. > While rxtx-2.1-7 probably has problems, The CVS code should be OK for 64 bit Solaris. If it isn't, let me know and I'll find which patch is missing. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Aug 5 23:13:00 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 23:13:00 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48986E20.3060104@ergotech.com> References: <48986E20.3060104@ergotech.com> Message-ID: On Tue, 5 Aug 2008, Jim Redman wrote: > Trent, > > So two issues: > > 1) Technically I'm still not sure how easy/practical a layer would be. The > problems are always classes like listeners, and wrapping returns of gnu.io > classes. I really see it as a "delegate" type of concept. Any thoughts or > ideas of the practicality of this approach? The idea is not to modify RXTX. I have not put too much thought into this. I assume you want what rxtx 2.0 provided to tie into javax.comm implementations. More classes could be added to rxtx 2.1-7 for SPI support. Maintaining rxtx-2.0 could also be handed to someone if they like. > > 2) Javax. The javax namespace does seem to be in widespread use outside of > Sun (the same is true for the java namespace). The classpath extensions, or > some other location, should be interested in a JavaComm implementation even > if it does have dependencies on RXTX. Would you have any philosophical > objection to an approach like that? > No problems. Classpathx would be a possible place to do it. I'd suggest thinking twice about what this involves in practical terms. You would be wanting to revive the 2.0 API while Sun is at 3.0 and grandfathering the JSR. This undermines the main reason (established api) for using the javax.comm namespace and does not leave such a project in a good position. The only win I see here is maintaining support for applications that can't migrate namespaces. Not that that isn't important. At some point it is going to be less work to just edit the bytecode :) Such a javax.comm effort would also be signing up new projects that decided to use the work up for concerns they probably will not understand or expect. That probably isn't a good path to facilitate for new projects at this time. We will put a good faith effort to work well with others but keep in mind the project has limited bandwidth for such efforts. > Of course, I suspect it might be better if someone with that authority at Sun > would admit that the javax namespace is already in the wild and that there is > no problem with it being used within RXTX. > > Jim > > Trent Jarvi wrote: >> Hi Jim, >> >> I will not step into the javax.comm namespace without Sun's explicite >> permission. I fully understand the pain point you are trying to address. >> >> In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java >> Comm Linux) - which remains an integral part of rxtx. At the time it was a >> win for Sun and rxtx. >> >> The Sun commapi license is/was fairly clear that rxtx should not step into >> that namespace. It made sense as Sun was active in that space and rxtx may >> go into another namespace - it was an experiment in working with Sun. >> >> This may sound silly looking at something that happened almost 10 years >> ago. In a community of respect which Sun helped create, there is no >> question about what to do. I hope eventually Sun will step up and do a >> right thing too. >> >> I agree that this is hurting the API more than helping it. There are also >> questions about how to replace the API in the long term which includes HID >> support which isn't going well so far. >> >> Others that can't even look at Sun's javax.comm today and can look at >> Kaffe's contribution to classpathx can easily work around such >> restrictions. >> >> On Mon, 4 Aug 2008, Jim Redman wrote: >> >>> Has there been any work/would it be possible, to layer a javacomm >>> look-alike on top of the GNU code? >>> >>> The goal is not to move the javax code forward, but to emulate the >>> "legacy" javax packages for people who still need this. >>> >>> Jim >>> >>> Trent Jarvi wrote: >>>> It would be nice to work with Sun to resolve those longstanding issues. >>>> But it may not be practical unless the process goes as fast and painless >>>> as the grandfathering of commapi did. >>>> >>>> Another option may be the old kaffe extensions that moved to gnu >>>> classpathx. These don't have the native libraries but should provide >>>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>>> >>>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From sandeep at genevasoftech.com Wed Aug 6 00:03:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Wed, 06 Aug 2008 11:33:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: <48993EB8.30107@genevasoftech.com> Thank you Mr. Martin for your suggestion. The native file which is given in rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am getting the following error . Any suggestions to solve this issue. I am using Solaris SPARC 64 bit machine. ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) thrown while loading gnu.io.RXTXCommDriver Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(Unknown Source) at java.lang.ClassLoader.loadLibrary(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) at com.ReadFromModem.main(ReadFromModem.java:84) * * *Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid > that then > you're out of luck since I think that quite a bit of RXTX is not yet ready > for 64 bit. > > Cheers, > -- > *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > ------------------------------------------------------------------------ > *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On > Behalf Of *Sandeep Kumar K > *Sent:* Tuesday, August 05, 2008 7:19 PM > *To:* rxtx at qbang.org > *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so > for Solaris 9 > > Hi, > > Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 > bit machine. The librxtxSerial.so given in website is for Solaris 8. > > *-- > > Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/1e920343/attachment-0029.html From tjarvi at qbang.org Wed Aug 6 00:21:42 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 00:21:42 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <48993EB8.30107@genevasoftech.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> <48993EB8.30107@genevasoftech.com> Message-ID: Hi Sandeep You may be out of luck unless you can compile the 2.1 src in CVS (requires gnu make and gcc). But you could try the ToyBox(R)(TM) which is a collection of WiLdLy untested cross compiled 2.1-7 binaries covering everything from the ibm z series to embeded arm/ppc. To give an idea how poorly these are tested, I don't even know if z series machines have a serial port. ftp://www.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Solaris They should at least match the binary types. Actually, I think if you use the rxtx jar from CVS with that file, it should 'work' as the fix for 64 bits was in java not the native code. You could just cd rxtx*/src; javac *.java then jar -cf RXTXcomm.jar `find -name \*.class` to create the hybrid which will complain about version information a bit. On Wed, 6 Aug 2008, Sandeep Kumar K wrote: > Thank you Mr. Martin for your suggestion. The native file which is given in > rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am > getting the following error . > Any suggestions to solve this issue. > I am using Solaris SPARC 64 bit machine. > > ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar > java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 > (Possible cause: architecture word > width mismatch) thrown while loading gnu.io.RXTXCommDriver > Exception in thread "main" java.lang.UnsatisfiedLinkError: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF > class: ELFCLASS64 (Possible cause: > architecture word width mismatch) > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(Unknown Source) > at java.lang.ClassLoader.loadLibrary(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > at com.ReadFromModem.main(ReadFromModem.java:84) > > * > * > > *Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > > > Oberhuber, Martin wrote: >> Sandeep, >> shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse >> variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on >> Sol7 but I've successfully run it on Sol9 and Sol10. >> Or is your request really about a native 64bit variant? I'm afraid that >> then >> you're out of luck since I think that quite a bit of RXTX is not yet ready >> for 64 bit. >> Cheers, >> -- >> *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> ------------------------------------------------------------------------ >> *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On >> Behalf Of *Sandeep Kumar K >> *Sent:* Tuesday, August 05, 2008 7:19 PM >> *To:* rxtx at qbang.org >> *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so >> for Solaris 9 >> >> Hi, >> >> Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 >> bit machine. The librxtxSerial.so given in website is for Solaris 8. >> >> *-- >> Thanks & Regards >> >> Sandeep Kumar K >> Sr. Software Engineer >> Geneva Software Technologies >> Whitefield, Bangalore >> Mob : 9880193454* >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> From michael.erskine at ketech.com Wed Aug 6 01:39:28 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 6 Aug 2008 08:39:28 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Florian Manschwetus wrote: > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) Hi Florian, I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. Regards, Michael Erskine. From florianmanschwetus at gmx.de Wed Aug 6 02:53:16 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 06 Aug 2008 10:53:16 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Message-ID: <4899667C.6010706@gmx.de> Michael Erskine schrieb: > Florian Manschwetus wrote: >> Ok, sounds fine for the receiving problem. >> But why i have to wait after each byte when sending a command squence? >> (the for loop in send command) > > Hi Florian, > I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. > > Regards, > Michael Erskine. > correct with a terminal on the other end it works, my idea was that this basic baud has some influence. Could some one explain what it is for? Florian > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/c2b4fa84/attachment-0029.bin From rick_knight at rlknight.com Wed Aug 6 13:01:07 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:01:07 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F4F3.3020707@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > I have an application (Readerware) that uses RXTX with Javax to access the serial port. This used to work fine under previous Linux' and Java, but something has changed, I assume with Java itself , that is causing the application to fail with a link error. The application is not able to find librxtxSerialParallel.so. RXTX supplies librxtxSerial.so and librxtxParallel.so, but not librxtxSerialParallel.so. Where can I get librxtxSerialParallel.so, or do I need it? Is something else causing the lib to not be found? Thanks, Rick Knight From rick_knight at rlknight.com Wed Aug 6 13:17:55 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:17:55 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F8E3.5060400@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Thanks for the reply. The developer of the app I'm trying to use (Readerware) has sent me a copy of the comm.api and I've copied the library (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar into the proper places. When I try to run the application, I get this error... Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: /usr/lib/libSolarisSerialParallel.so: /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not little-endian (Possible cause: endianness mismatch) Caught java.lang.UnsatisfiedLinkError: com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I while loading driver com.sun.comm.SolarisDriver Is there a way around this error? Thanks again, Rick Knight From jlar310 at gmail.com Wed Aug 6 13:37:42 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 14:37:42 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899F8E3.5060400@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > The developer of the app I'm trying to use (Readerware) has sent me a > copy of the comm.api and I've copied the library > (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar > into the proper places. When I try to run the application, I get this > error... > > Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: > /usr/lib/libSolarisSerialParallel.so: > /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not > little-endian (Possible cause: endianness mismatch) > Caught java.lang.UnsatisfiedLinkError: > com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I > > while loading driver com.sun.comm.SolarisDriver > > Is there a way around this error? What host OS are you running? From your original post it looks like 32 bit Linux. The libSolarisSerialParallel.so file is for Sun Solaris and will vary depending on the underlying hardware architecture as well. Sorry for the double post Rick, but I failed to send this to the list the first time... -- Jeff From rick_knight at rlknight.com Wed Aug 6 13:44:29 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:44:29 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: <4899FF1D.9030504@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > > >> The developer of the app I'm trying to use (Readerware) has sent me a >> copy of the comm.api and I've copied the library >> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >> into the proper places. When I try to run the application, I get this >> error... >> >> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >> /usr/lib/libSolarisSerialParallel.so: >> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >> little-endian (Possible cause: endianness mismatch) >> Caught java.lang.UnsatisfiedLinkError: >> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >> >> while loading driver com.sun.comm.SolarisDriver >> >> Is there a way around this error? >> > > What host OS are you running? From your original post it looks like 32 > bit Linux. > > The libSolarisSerialParallel.so file is for Sun Solaris and will vary > depending on the underlying hardware architecture as well. > > I'm running Kubuntu Linux (debian based). It's 32 bit. Rick Knight From jlar310 at gmail.com Wed Aug 6 15:33:23 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 16:33:23 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > I don't think Sun did binary libraries for Linux in the 2.0 version. Can someone with more historical experience than I confirm that? I recently tried to port a Comm API application from Solaris sparc to Linux x86 and likewise could not get my hands on the binary libraries. I eventually just re-wrote the code to use the gnu namespace packages and rxtx 2.1. What I don't understand is why your application vendor does not provide everything you need to run their software. FYI: I have librxtxParallel.so and librxtxSerial.so installed at JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is /usr/java/default which is actually a softlink to /usr/java/jre1.6.0_05. -- Jeff From defiantlew at yahoo.com.au Wed Aug 6 16:29:33 2008 From: defiantlew at yahoo.com.au (Lew L) Date: Thu, 7 Aug 2008 08:29:33 +1000 Subject: [Rxtx] Sun's Comm API Documentation References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> Message-ID: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> As a matter of interest is the Sun Comm API documentation available somewhere? I have tried the Sun site but it seems to have been removed. Unless I have missed the documentation for RXTX? I javadocced the RXTX source but information (to me) is minimal. Somewhere I got the impression that the Sun Comm API docs is, or was, compatible with RXTX, what is the best docs to use in conjuntion with RXTX and where may the be available? Cheers Lew From rick_knight at rlknight.com Wed Aug 6 17:18:33 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:18:33 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A3149.4050306@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff I'm not sure if I posted this here or not, but when I try to build RXTX from source I get this install error... make all-am make[1]: Entering directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' make[1]: Nothing to be done for `all-am'. make[1]: Leaving directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 Can you tell me how to get past this error and get RXTX built and installed? Thanks, Rick From bboyes at systronix.com Wed Aug 6 17:40:12 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Wed, 06 Aug 2008 17:40:12 -0600 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: At 16:29 08/06/2008, Lew L wrote: >As a matter of interest is the Sun Comm API documentation available >somewhere? I have tried the Sun site but it seems to have been removed. It's in the file we have posted, link in prev email (sorry, in a huge hurry right now). Javadocs definitely there. >Unless I have missed the documentation for RXTX? I javadocced the RXTX >source but information (to me) is minimal. >Somewhere I got the impression that the Sun Comm API docs is, or was, >compatible with RXTX, what is the best docs to use in conjuntion with RXTX >and where may the be available? Yeah, this is one of my concerns/beefs. There is little documentation for RXTX and it isn't just the same as javaxcomm. I would be willing to help out writing docs for RXTX! Yes really... esp if we can fix the Bluetooth issues. best regards Bruce >Cheers >Lew > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx ------- WWW.SYSTRONIX.COM ---------- Real embedded Java and much more +1-801-534-1017 Salt Lake City, USA From rick_knight at rlknight.com Wed Aug 6 17:54:08 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:54:08 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A39A0.2090309@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff, I would like for my vendor to switch to rxtx 2.1. It would make things much easier for me. I'm not sure why he's still using the javax compatible code. He's a small operation. Re-writing the code to use gnu namespace sounds like a major overhaul. Was it? Thanks, Rick From tjarvi at qbang.org Wed Aug 6 21:35:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:35:12 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: >> >>> Jeff wrote: >>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>>> >>>> >>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things > much easier for me. I'm not sure why he's still using the javax > compatible code. He's a small operation. Re-writing the code to use gnu > namespace sounds like a major overhaul. Was it? > Hi Jeff, The changes are fairly mechanical. Imports need to change and any explicite use of the namespace needs to change such as catching an exception. The following script was made for maintaining rxtx 2.0 but can apply to other needs. It is in the contrib dir with rxtx source. #!/bin/sh # Don't use! :) # # Sat, 03 May 2003 16:45:08 Modifications from J?rg Weule # Create a ed-cmd for the change of one pattern # case $1 in gnu) X=g/javax_comm/s+javax_comm+gnu_io+g ;; javax) X=g/gnu_io/s+gnu_io+javax_comm+g ;; *) echo;echo;echo From the top rxtx directory run;echo;echo -e \\t./ChangePackage.sh gnu;echo -e \\t\\tor;echo -e \\t./ChangePackage.sh javax;echo;echo; exit 0 ;; esac # # ed will be used to keep the owner and mode of the files unchanged. # We have run the ed-script for the characters '.' '/' as well. # "tr _ $D" do the change. # find . -type f -a -print | grep -v $0 | (while read F ; do ( echo $X; echo $X| tr _ /; echo $X| tr _ .; echo w; echo q ) | ed $F 2>&1 >/dev/null done ) # # Now we do little changes at the Makefiles. Hope that all we need. # find . -name Makefile\* -a -print | (while read F ; do cat < References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: On Thu, 7 Aug 2008, Lew L wrote: > As a matter of interest is the Sun Comm API documentation available > somewhere? I have tried the Sun site but it seems to have been removed. > > Unless I have missed the documentation for RXTX? I javadocced the RXTX > source but information (to me) is minimal. > Somewhere I got the impression that the Sun Comm API docs is, or was, > compatible with RXTX, what is the best docs to use in conjuntion with RXTX > and where may the be available? > Hi Lew, The documentation on Sun's website is accurate. The changes that are problematic in 3.0 are on the backside which rxtx used to plug into. http://java.sun.com/products/javacomm/reference/api/index.html CommPortIdentifier may have some minor differences (judging by the authors notes). -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Aug 6 21:46:08 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:46:08 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > If javax.comm.properties is properly installed and you are using a 2.0 version of Sun's commapi with rxtx 2.0, you should not see the library attempt to load libSolarisSerialParallel.so. Sun CommAPI 3.0 will not work with any version of rxtx as it is hard coded to use the shared library. See the INSTALL file with rxtx-2.0 source for more help with the properties file. -- Trent Jarvi tjarvi at qbang.org From jlar310 at gmail.com Thu Aug 7 06:32:06 2008 From: jlar310 at gmail.com (Jeff) Date: Thu, 7 Aug 2008 07:32:06 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > Jeff wrote: >> >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >> wrote: >> >>> >>> Jeff wrote: >>> >>>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>> wrote: >>>> >>>> >>>> >>>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things much > easier for me. I'm not sure why he's still using the javax compatible code. > He's a small operation. Re-writing the code to use gnu namespace sounds like > a major overhaul. Was it? I found it quite easy. In fact, in order to accommodate the transition, I actually separated all of the code that deals directly with the Comm API or RXTX into a helper class. The helper class was then coded to use reflection to determine which library was available and then instantiate the necessary objects. No direct imports of either library are used. The main application just needs to get it's hands on the IO streams and need not deal directly with the libraries. Other programs may not be so simple... But this doesn't really help you unless your vendor forks over the source code... -- Jeff From rick_knight at rlknight.com Thu Aug 7 09:47:12 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Thu, 07 Aug 2008 08:47:12 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: <489B1900.10108@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >>> wrote: >>> >>> >>>> Jeff wrote: >>>> >>>> >>>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>>> copy of the comm.api and I've copied the library >>>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>>> into the proper places. When I try to run the application, I get this >>>>>> error... >>>>>> >>>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>>> /usr/lib/libSolarisSerialParallel.so: >>>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>>> little-endian (Possible cause: endianness mismatch) >>>>>> Caught java.lang.UnsatisfiedLinkError: >>>>>> >>>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>>> >>>>>> while loading driver com.sun.comm.SolarisDriver >>>>>> >>>>>> Is there a way around this error? >>>>>> >>>>>> >>>>>> >>>>> What host OS are you running? From your original post it looks like 32 >>>>> bit Linux. >>>>> >>>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>>> depending on the underlying hardware architecture as well. >>>>> >>>>> >>>>> >>>>> >>>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>>> >>>> >>>> >>> I don't think Sun did binary libraries for Linux in the 2.0 version. >>> Can someone with more historical experience than I confirm that? >>> >>> I recently tried to port a Comm API application from Solaris sparc to >>> Linux x86 and likewise could not get my hands on the binary libraries. >>> I eventually just re-wrote the code to use the gnu namespace packages >>> and rxtx 2.1. >>> >>> What I don't understand is why your application vendor does not >>> provide everything you need to run their software. >>> >>> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >>> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >>> /usr/java/default which is actually a softlink to >>> /usr/java/jre1.6.0_05. >>> >>> >>> >> Jeff, >> >> I would like for my vendor to switch to rxtx 2.1. It would make things much >> easier for me. I'm not sure why he's still using the javax compatible code. >> He's a small operation. Re-writing the code to use gnu namespace sounds like >> a major overhaul. Was it? >> > > I found it quite easy. In fact, in order to accommodate the > transition, I actually separated all of the code that deals directly > with the Comm API or RXTX into a helper class. The helper class was > then coded to use reflection to determine which library was available > and then instantiate the necessary objects. No direct imports of > either library are used. The main application just needs to get it's > hands on the IO streams and need not deal directly with the libraries. > Other programs may not be so simple... > > But this doesn't really help you unless your vendor forks over the > source code... > > Jeff, This may not help me directly, but I'm going to forward this thread to the vendor. I think he'll be open to making things work. Thanks again, Rick Knight From agusmunioz at gmail.com Thu Aug 7 16:39:51 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Thu, 7 Aug 2008 19:39:51 -0300 Subject: [Rxtx] How to send ack? Message-ID: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Hi, I'm still learning about serial communication and I have some doubts. I've got this question about how to do the following thing in rxtx. I have this hardware that connect to a PC using a serial port. These hardware receives data from a telephone line, proccess it, and then send it forward to the serial port. I've used a program named wincomm that shows what information is send it through the serial port and I have the nex behaviour: The hardware has a buffer where all data is stored, that cannot be sent it through the seria port. The program reads the first data send it by the hardware, and keep reading the same data always. There is a button in the application that says enable Ack, and when I click, then the hardware start to send all the stored information, and all the information is shown. I write a class, using rxtx that reads the serial port, and the same thing happens, it remains reading the same (first) data all the time. And I thing something like the enable Ack I'm missing. How can I do this enable Ack from my java code using rxtx? Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080807/e0a0f9a1/attachment-0027.html From ajmas at sympatico.ca Thu Aug 7 18:26:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 7 Aug 2008 20:26:41 -0400 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: <4BF42297-81E2-4BB8-A89F-1D43588379AE@sympatico.ca> On 6-Aug-08, at 19:40 , Bruce Boyes wrote: >> Unless I have missed the documentation for RXTX? I javadocced the >> RXTX >> source but information (to me) is minimal. >> Somewhere I got the impression that the Sun Comm API docs is, or was, >> compatible with RXTX, what is the best docs to use in conjuntion >> with RXTX >> and where may the be available? > > Yeah, this is one of my concerns/beefs. There is little documentation > for RXTX and it isn't just the same as javaxcomm. > > I would be willing to help out writing docs for RXTX! Yes really... > esp if we can fix the Bluetooth issues. If you want to contribute documentation then the best place to do that is the wiki. If there is anything missing or that could be improved on then please do so. If there are any points that you would like to see improved, for which you don't have the knowledge then ask on the mailing list for a volunteer. Andre From florianmanschwetus at gmx.de Fri Aug 8 03:04:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Fri, 08 Aug 2008 11:04:14 +0200 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Message-ID: <489C0C0E.2020401@gmx.de> Agustin Mu?oz schrieb: > Hi, I'm still learning about serial communication and I have some > doubts. I've got this question about how to do the following thing in rxtx. > I have this hardware that connect to a PC using a serial port. These > hardware receives data from a telephone line, proccess it, and then send > it forward to the serial port. I've used a program named wincomm that > shows what information is send it through the serial port and I have the > nex behaviour: > > The hardware has a buffer where all data is stored, that cannot be sent > it through the seria port. > The program reads the first data send it by the hardware, and keep > reading the same data always. > There is a button in the application that says enable Ack, and when I > click, then the hardware start to send all the stored information, and > all the information is shown. > > I write a class, using rxtx that reads the serial port, and the same > thing happens, it remains reading the same (first) data all the time. > And I thing something like the enable Ack I'm missing. > How can I do this enable Ack from my java code using rxtx? Afaik, a look at man ascii reveals: Okt Dez Hex Char 006 6 06 ACK So, i hope this will do the job: send(6); florian > > Thanks in advance > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/5b4965f8/attachment-0027.bin From agusmunioz at gmail.com Fri Aug 8 16:31:00 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 19:31:00 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <489C0C0E.2020401@gmx.de> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> Message-ID: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Hi Florian, thanks for the answer. By send(6) you mean to get the port OutputStream and write a 6? I try that but it didn't work. Any suggestion? Thanks On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < florianmanschwetus at gmx.de> wrote: > Agustin Mu?oz schrieb: > > Hi, I'm still learning about serial communication and I have some doubts. >> I've got this question about how to do the following thing in rxtx. >> I have this hardware that connect to a PC using a serial port. These >> hardware receives data from a telephone line, proccess it, and then send it >> forward to the serial port. I've used a program named wincomm that shows >> what information is send it through the serial port and I have the nex >> behaviour: >> >> The hardware has a buffer where all data is stored, that cannot be sent >> it through the seria port. >> The program reads the first data send it by the hardware, and keep reading >> the same data always. >> There is a button in the application that says enable Ack, and when I >> click, then the hardware start to send all the stored information, and all >> the information is shown. >> >> I write a class, using rxtx that reads the serial port, and the same thing >> happens, it remains reading the same (first) data all the time. And I thing >> something like the enable Ack I'm missing. >> How can I do this enable Ack from my java code using rxtx? >> > Afaik, a look at man ascii reveals: > Okt Dez Hex Char > 006 6 06 ACK > So, i hope this will do the job: > send(6); > > florian > >> >> Thanks in advance >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/7f3fba42/attachment-0026.html From agusmunioz at gmail.com Fri Aug 8 18:39:27 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 21:39:27 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Message-ID: <988288430808081739x7f9e7889id82591d5a9e2b4f6@mail.gmail.com> Ok, Florian, it works!! my problem was that I've been sending, through the OutputStream, the bytes of 6 as a string: out.write("6".getBytes()); but then I realized that you can write an int on an OuptuStream, so I tried that and It works: out.write(6); Thank you for the guidance!! On Fri, Aug 8, 2008 at 7:31 PM, Agustin Mu?oz wrote: > Hi Florian, thanks for the answer. By send(6) you mean to get the port > OutputStream and write a 6? > > I try that but it didn't work. > > Any suggestion? > > Thanks > > > On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < > florianmanschwetus at gmx.de> wrote: > >> Agustin Mu?oz schrieb: >> >> Hi, I'm still learning about serial communication and I have some doubts. >>> I've got this question about how to do the following thing in rxtx. >>> I have this hardware that connect to a PC using a serial port. These >>> hardware receives data from a telephone line, proccess it, and then send it >>> forward to the serial port. I've used a program named wincomm that shows >>> what information is send it through the serial port and I have the nex >>> behaviour: >>> >>> The hardware has a buffer where all data is stored, that cannot be sent >>> it through the seria port. >>> The program reads the first data send it by the hardware, and keep >>> reading the same data always. >>> There is a button in the application that says enable Ack, and when I >>> click, then the hardware start to send all the stored information, and all >>> the information is shown. >>> >>> I write a class, using rxtx that reads the serial port, and the same >>> thing happens, it remains reading the same (first) data all the time. And I >>> thing something like the enable Ack I'm missing. >>> How can I do this enable Ack from my java code using rxtx? >>> >> Afaik, a look at man ascii reveals: >> Okt Dez Hex Char >> 006 6 06 ACK >> So, i hope this will do the job: >> send(6); >> >> florian >> >>> >>> Thanks in advance >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/b918ab3d/attachment-0026.html From florianmanschwetus at gmx.de Sat Aug 9 00:45:43 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Sat, 09 Aug 2008 08:45:43 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4899667C.6010706@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> Message-ID: <489D3D17.9090209@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >> Florian Manschwetus wrote: >>> Ok, sounds fine for the receiving problem. >>> But why i have to wait after each byte when sending a command squence? >>> (the for loop in send command) >> >> Hi Florian, >> I'd imagine you probably don't! You could send all bytes in one go and >> RXTX would send them. The problem is most probably the other end: >> perhaps it has a really small buffer, some non-standard UART, or a >> crazy timing issue. If you attach a terminal to your output and send >> all the bytes of a command in one go they should appear no problem. >> >> Regards, >> Michael Erskine. >> > correct with a terminal on the other end it works, my idea was that this > basic baud has some influence. Could some one explain what it is for? > > Florian To make it more clear, my problem is that i can't use: outputStream.write(byte[]); => Beamer doesn't understand the sequence. (mostly no answer when he answers then *001) when i use this construct instead: for (int i = 0; i < command.length; i++) { this.outputStream.write(command[i]); try { Thread.sleep(25); } catch (InterruptedException e) { // TODO Auto-generated catch block e.printStackTrace(); } } it works nearly reliable. So what could it be? This Basic Baud is what exactly? Florian -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080809/692304ee/attachment-0026.bin From tjarvi at qbang.org Sat Aug 9 16:37:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Aug 2008 16:37:19 -0600 (MDT) Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489D3D17.9090209@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> <489D3D17.9090209@gmx.de> Message-ID: On Sat, 9 Aug 2008, Florian Manschwetus wrote: > Florian Manschwetus schrieb: >> Michael Erskine schrieb: >>> Florian Manschwetus wrote: >>>> Ok, sounds fine for the receiving problem. >>>> But why i have to wait after each byte when sending a command squence? >>>> (the for loop in send command) >>> >>> Hi Florian, >>> I'd imagine you probably don't! You could send all bytes in one go and >>> RXTX would send them. The problem is most probably the other end: perhaps >>> it has a really small buffer, some non-standard UART, or a crazy timing >>> issue. If you attach a terminal to your output and send all the bytes of a >>> command in one go they should appear no problem. >>> >>> Regards, >>> Michael Erskine. >>> >> correct with a terminal on the other end it works, my idea was that this >> basic baud has some influence. Could some one explain what it is for? >> >> Florian > To make it more clear, > my problem is that i can't use: > outputStream.write(byte[]); > => Beamer doesn't understand the sequence. (mostly no answer when he answers > then *001) > > when i use this construct instead: > > for (int i = 0; i < command.length; i++) { > this.outputStream.write(command[i]); > try { > Thread.sleep(25); > } catch (InterruptedException e) { > // TODO Auto-generated catch block > e.printStackTrace(); > } > } > > it works nearly reliable. > > So what could it be? This Basic Baud is what exactly? > I suspect you are using the 'moon protocol' and don't know it. RXTX enables this by default. The buffer on the other end is first in first out while reading. If the buffer is full, the bits are hand carried to the moon and burried. Then if the other side reads a couple bytes, two more bytes go into the buffer followed by more moon protocol. The resulting array of bytes the other side reads may appear to be scrambled until you go to the moon, get the bits and insert them in the right place. Flow control can prevent the default moon protocol and throttles the communiation by almost writing a byte at a time as need be. Hardware flow control is preferable but software flow control should also work. Read and write can appear to hang if the other side is not connected. This is why we don't enable them all the time. If you can't use flow control, you have to take care with the moon protocol and give the other side time to read. That is what your slower version of write is doing. -- Trent Jarvi tjarvi at qbang.org From rxtx at allenjb.me.uk Mon Aug 11 08:06:36 2008 From: rxtx at allenjb.me.uk (AllenJB) Date: Mon, 11 Aug 2008 15:06:36 +0100 Subject: [Rxtx] Disabling EV_RXFLAG Message-ID: <48A0476C.2090800@allenjb.me.uk> Hi all, I'm working with a device which does not use an EvtChar and need to disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an event mask of FD 01 00 00. The reference software I have uses FB 00 00 00. With the rxtx mask I get framing errors which I believe are caused when the EvtChar is received. Is there currently a way with rxtx (I've using rxtx from Java) to disable EV_RXFLAG? If not from Java, where would I start if I wanted to turn the EV_RXFLAG option off in the C code? I've had a grep of the rxtx source code, but I can't see where EV_RXFLAG is being set. Thanks in advance, AllenJB From tjarvi at qbang.org Mon Aug 11 14:17:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Aug 2008 14:17:27 -0600 (MDT) Subject: [Rxtx] Disabling EV_RXFLAG In-Reply-To: <48A0476C.2090800@allenjb.me.uk> References: <48A0476C.2090800@allenjb.me.uk> Message-ID: On Mon, 11 Aug 2008, AllenJB wrote: > Hi all, > > I'm working with a device which does not use an EvtChar and need to > disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an > event mask of FD 01 00 00. The reference software I have uses FB 00 00 > 00. With the rxtx mask I get framing errors which I believe are caused > when the EvtChar is received. > > Is there currently a way with rxtx (I've using rxtx from Java) to > disable EV_RXFLAG? > > If not from Java, where would I start if I wanted to turn the EV_RXFLAG > option off in the C code? I've had a grep of the rxtx source code, but I > can't see where EV_RXFLAG is being set. > > Thanks in advance, > > AllenJB Hi Allen, I'd look at termios.c::tcsetattr() and termios.c::FillDCB() -- Trent Jarvi tjarvi at qbang.org From superdadusa at gmail.com Tue Aug 12 13:57:32 2008 From: superdadusa at gmail.com (John Choi) Date: Tue, 12 Aug 2008 13:57:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. Message-ID: Hi all, Just let you all know I just start to learn Java. I have download the serial comm package and the source code from open source communities.. I was able to verify with the given message string via serial monitor. when the given message string sends to the serial port then the character return added to the end of string by default if I use "Hello World" however if I changed to something else other than "Hello, World" there is no character return add to the end of string. I thing the library download from rxtx.org has implemented for the special strings. I can do like "login\n" in the string message to make character return but I don't want to add this individual custom character for each command return in every static message string I send, Can any who have done this might help me? Basically, something like this,, Write and add function to the program write a command, Reads the respond from a serial device.. Function handles multiple messages, Write: "com open" Read: Welcome to my world" expected Write: "admin" Read: Password?, expected Write: "admin" Read: you are successfully login terminal, expected. And I need to add a separate function handler handles a character return add to the each command above. If anyone can help this I can do the reset? Thank you in advance, John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0022.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SerialIO.java Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0022.pl From Steffen.DETTMER at ingenico.com Wed Aug 13 02:16:38 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 13 Aug 2008 10:16:38 +0200 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: References: Message-ID: <20080813081638.GA25412@elberon.bln.de.ingenico.com> * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > I can do like "login\n" in the string message to make character > return but I don't want to add this individual custom character > for each command return in every static message string I send, and why not?! > Can any who have done this might help me? what's about with writing a small wrapper function adding the carriage return? However, this would be slow, because either you call write two times (very bad) or the string needs to be copied, \n appended and written (since you are using Java Performance probably isn't so critical). Personally I would write `"login\n"' and `username + "\n"' etc., because since it is part of the command it should be part of the command definition string. > Basically, something like this,, Write and add function to the program write > a command, Reads the respond from a serial device.. correctly reading a `line' is more difficult. If you cannot make assumptions about timeouts and/or you need to have low delay, you need to read byte wise. If you need to save CPU resources you might need to add some buffering layer that you can read byte-wise but that is reading blockwise with some small timeout (lets say for serial lines something around byte transmission time times three or so). > /* > * To change this template, choose Tools | Templates > * and open the template in the editor. > */ :) > package joliba; > > /** > * > * @author root > */ :) > // derived from SUN's examples in the javax.comm package > import java.io.*; > import java.util.*; > //import javax.comm.*; // for SUN's serial/parallel port libraries > import gnu.io.*; // for rxtxSerial library > > public class SerialIO implements Runnable, SerialPortEventListener { > static CommPortIdentifier portId; > static CommPortIdentifier saveportId; > static Enumeration portList; > InputStream inputStream; > SerialPort serialPort; > Thread readThread; You need a thread for your synchronous RPC-style protocol? > static String messageString = "Hello, world!"; > static OutputStream outputStream; > static boolean outputBufferEmptyFlag = false; > > public static void main(String[] args) { > boolean portFound = false; > String defaultPort; > > // determine the name of the serial port on several operating systems > String osname = System.getProperty("os.name","").toLowerCase(); > if ( osname.startsWith("windows") ) { > // windows > defaultPort = "COM1"; > } else if (osname.startsWith("linux")) { > // linux > defaultPort = "/dev/ttyS0"; > } else if ( osname.startsWith("mac") ) { > // mac > defaultPort = "????"; > } else { > System.out.println("Sorry, your operating system is not supported"); > return; > } Is such a construction recommended? Isn't there some abstraction (like COM1 working on any platform)? [...] > try { > // activate the OUTPUT_BUFFER_EMPTY notifier > serialPort.notifyOnOutputEmpty(true); > } catch (Exception e) { > System.out.println("Error setting event notification"); > System.out.println(e.toString()); > System.exit(-1); > } I doubt that -1 is defined, probably some 127 or so would be the result, maybe better simply `throw e'? > public void writetoport() { > System.out.println("Writing \""+messageString+"\" to "+serialPort.getName()); > try { > // write string to serial port > outputStream.write(messageString.getBytes()); > } catch (IOException e) {} > } maybe something like /** * Writes the given output string and an additional carriage * return to the current outputStream. */ public void writeStringToPort( /** The output string (without CR). */ String output ) throws IOException { String outputLine = output + "\n"; outputStream.write(outputLine.getBytes()); } ? > > public SerialIO() { > // initalize serial port > try { > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > } catch (PortInUseException e) {} if the port is in use, you continue? Wonder that this works in Java, I would assume serialPort beeing uninitialized which AFAIK is an error in Java. > try { > inputStream = serialPort.getInputStream(); > } catch (IOException e) {} > > try { > serialPort.addEventListener(this); > } catch (TooManyListenersException e) {} > > // activate the DATA_AVAILABLE notifier > serialPort.notifyOnDataAvailable(true); > > try { > // set port parameters > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > } catch (UnsupportedCommOperationException e) {} > > // start the read thread > readThread = new Thread(this); > readThread.start(); > > } I think in all those exception cases you can abort, because it is unlikely that ignoring those errors allow a successful continuation, so in this case maybe it would be better to add a throw clause to the method. > public void run() { > // first thing in the thread, we initialize the write operation > initwritetoport(); > try { > while (true) { > // write string to port, the serialEvent will read it > writetoport(); > Thread.sleep(1000); > } > } catch (InterruptedException e) {} > } Does this make sense? Your `SimpleReadApp' writes one and the same string each second? > public void serialEvent(SerialPortEvent event) { > switch (event.getEventType()) { > case SerialPortEvent.BI: > case SerialPortEvent.OE: > case SerialPortEvent.FE: > case SerialPortEvent.PE: > case SerialPortEvent.CD: > case SerialPortEvent.CTS: > case SerialPortEvent.DSR: > case SerialPortEvent.RI: > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > break; > case SerialPortEvent.DATA_AVAILABLE: > // we get here if data has been received > byte[] readBuffer = new byte[20]; > try { > // read data > while (inputStream.available() > 0) { > int numBytes = inputStream.read(readBuffer); > } > // print data > String result = new String(readBuffer); > System.out.println("Read: "+result); > } catch (IOException e) {} I doubt that this is correct. I would assume you will get a 20 bytes result always, if more bytes would be available they would be printed in a second line but if less bytes are read I'd assume that the buffer/result contains zero bytes from implicite readBuffer contents initialisation (zero is no string terminator in Java AFAIK). > break; > } > } > } oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From florianmanschwetus at gmx.de Wed Aug 13 06:09:31 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 13 Aug 2008 14:09:31 +0200 Subject: [Rxtx] someone has seen such errors? Message-ID: <48A2CEFB.90007@gmx.de> I mean my communication mostly works, but it is far from perfect could this be the reason? Florian Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/949b9947/attachment-0022.bin From superdadusa at gmail.com Wed Aug 13 08:40:32 2008 From: superdadusa at gmail.com (John Choi) Date: Wed, 13 Aug 2008 08:40:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: <20080813081638.GA25412@elberon.bln.de.ingenico.com> References: <20080813081638.GA25412@elberon.bln.de.ingenico.com> Message-ID: Thank you so much Steffen and I will try that suggestion. John On 8/13/08, Steffen DETTMER wrote: > > * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > > I can do like "login\n" in the string message to make character > > return but I don't want to add this individual custom character > > for each command return in every static message string I send, > > and why not?! > > > Can any who have done this might help me? > > what's about with writing a small wrapper function adding the > carriage return? > However, this would be slow, because either you call write two > times (very bad) or the string needs to be copied, \n appended > and written (since you are using Java Performance probably isn't > so critical). > > Personally I would write `"login\n"' and `username + "\n"' etc., > because since it is part of the command it should be part of the > command definition string. > > > Basically, something like this,, Write and add function to the program > write > > a command, Reads the respond from a serial device.. > > correctly reading a `line' is more difficult. If you cannot make > assumptions about timeouts and/or you need to have low delay, you > need to read byte wise. If you need to save CPU resources you > might need to add some buffering layer that you can read > byte-wise but that is reading blockwise with some small timeout > (lets say for serial lines something around byte transmission > time times three or so). > > > /* > > * To change this template, choose Tools | Templates > > * and open the template in the editor. > > */ > > :) > > > package joliba; > > > > /** > > * > > * @author root > > */ > > :) > > > // derived from SUN's examples in the javax.comm package > > import java.io.*; > > import java.util.*; > > //import javax.comm.*; // for SUN's serial/parallel port libraries > > import gnu.io.*; // for rxtxSerial library > > > > public class SerialIO implements Runnable, SerialPortEventListener { > > static CommPortIdentifier portId; > > static CommPortIdentifier saveportId; > > static Enumeration portList; > > InputStream inputStream; > > SerialPort serialPort; > > Thread readThread; > > You need a thread for your synchronous RPC-style protocol? > > > static String messageString = "Hello, world!"; > > static OutputStream outputStream; > > static boolean outputBufferEmptyFlag = false; > > > > public static void main(String[] args) { > > boolean portFound = false; > > String defaultPort; > > > > // determine the name of the serial port on several operating > systems > > String osname = System.getProperty("os.name","").toLowerCase(); > > if ( osname.startsWith("windows") ) { > > // windows > > defaultPort = "COM1"; > > } else if (osname.startsWith("linux")) { > > // linux > > defaultPort = "/dev/ttyS0"; > > } else if ( osname.startsWith("mac") ) { > > // mac > > defaultPort = "????"; > > } else { > > System.out.println("Sorry, your operating system is not > supported"); > > return; > > } > > Is such a construction recommended? Isn't there some abstraction > (like COM1 working on any platform)? > > [...] > > try { > > // activate the OUTPUT_BUFFER_EMPTY notifier > > serialPort.notifyOnOutputEmpty(true); > > } catch (Exception e) { > > System.out.println("Error setting event notification"); > > System.out.println(e.toString()); > > System.exit(-1); > > } > > I doubt that -1 is defined, probably some 127 or so would be the > result, maybe better simply `throw e'? > > > public void writetoport() { > > System.out.println("Writing \""+messageString+"\" to > "+serialPort.getName()); > > try { > > // write string to serial port > > outputStream.write(messageString.getBytes()); > > } catch (IOException e) {} > > } > > maybe something like > > /** > * Writes the given output string and an additional carriage > * return to the current outputStream. > */ > public void > writeStringToPort( > /** The output string (without CR). */ > String output > ) throws IOException > { > String outputLine = output + "\n"; > outputStream.write(outputLine.getBytes()); > } > > ? > > > > > public SerialIO() { > > // initalize serial port > > try { > > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > > } catch (PortInUseException e) {} > > if the port is in use, you continue? Wonder that this works in > Java, I would assume serialPort beeing uninitialized which AFAIK > is an error in Java. > > > try { > > inputStream = serialPort.getInputStream(); > > } catch (IOException e) {} > > > > try { > > serialPort.addEventListener(this); > > } catch (TooManyListenersException e) {} > > > > // activate the DATA_AVAILABLE notifier > > serialPort.notifyOnDataAvailable(true); > > > > try { > > // set port parameters > > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > } catch (UnsupportedCommOperationException e) {} > > > > // start the read thread > > readThread = new Thread(this); > > readThread.start(); > > > > } > > I think in all those exception cases you can abort, because it is > unlikely that ignoring those errors allow a successful > continuation, so in this case maybe it would be better to add a > throw clause to the method. > > > public void run() { > > // first thing in the thread, we initialize the write operation > > initwritetoport(); > > try { > > while (true) { > > // write string to port, the serialEvent will read it > > writetoport(); > > Thread.sleep(1000); > > } > > } catch (InterruptedException e) {} > > } > > Does this make sense? Your `SimpleReadApp' writes one and the > same string each second? > > > public void serialEvent(SerialPortEvent event) { > > switch (event.getEventType()) { > > case SerialPortEvent.BI: > > case SerialPortEvent.OE: > > case SerialPortEvent.FE: > > case SerialPortEvent.PE: > > case SerialPortEvent.CD: > > case SerialPortEvent.CTS: > > case SerialPortEvent.DSR: > > case SerialPortEvent.RI: > > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > > break; > > case SerialPortEvent.DATA_AVAILABLE: > > // we get here if data has been received > > byte[] readBuffer = new byte[20]; > > try { > > // read data > > while (inputStream.available() > 0) { > > int numBytes = inputStream.read(readBuffer); > > } > > // print data > > String result = new String(readBuffer); > > System.out.println("Read: "+result); > > } catch (IOException e) {} > > I doubt that this is correct. I would assume you will get a 20 > bytes result always, if more bytes would be available they would > be printed in a second line but if less bytes are read I'd assume > that the buffer/result contains zero bytes from implicite > readBuffer contents initialisation (zero is no string terminator > in Java AFAIK). > > > break; > > } > > } > > } > > oki, > > Steffen > > About Ingenico Throughout the world businesses rely on Ingenico for secure > and expedient electronic transaction acceptance. Ingenico products leverage > proven technology, established standards and unparalleled ergonomics to > provide optimal reliability, versatility and usability. This comprehensive > range of products is complemented by a global array of services and > partnerships, enabling businesses in a number of vertical sectors to accept > transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged > information. If you are not the addressee or authorized to receive this for > the addressee, you must not use, copy, disclose or take any action based on > this message or any information herein. If you have received this message in > error, please advise the sender immediately by reply e-mail and delete this > message. Thank you for your cooperation. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/73c4135c/attachment-0021.html From ajmas at sympatico.ca Sat Aug 16 07:15:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 09:15:41 -0400 Subject: [Rxtx] someone has seen such errors? In-Reply-To: <48A2CEFB.90007@gmx.de> References: <48A2CEFB.90007@gmx.de> Message-ID: <43B5E8DA-1D93-4D90-809B-AAF35FF724C5@sympatico.ca> On 13-Aug-08, at 08:09 , Florian Manschwetus wrote: > I mean my communication mostly works, but it is far from perfect > could this be the reason? > > Florian > > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control Judging by the error messages this looks related to the driver you are using. Do a search for the following string with you favourite search engine, it should turn up a few hits: ftdi_set_termios FAILED to set databits/stopbits/parity Andre From ajmas at sympatico.ca Sat Aug 16 19:12:04 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 21:12:04 -0400 Subject: [Rxtx] Using SerialPortEvent? Message-ID: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Hi, Could someone tell me how I should be using the SerialPortEvent? Am I meant to be waiting for data and then simply reading from the inputstream? If this is the case why no just block on an inputstream read? Andr? From tjarvi at qbang.org Sat Aug 16 19:41:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 16 Aug 2008 19:41:13 -0600 (MDT) Subject: [Rxtx] Using SerialPortEvent? In-Reply-To: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> References: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Message-ID: On Sat, 16 Aug 2008, Andre-John Mas wrote: > Hi, > > Could someone tell me how I should be using the SerialPortEvent? Am I > meant to be waiting for data and then simply reading from the > inputstream? If this is the case why no just block on an inputstream > read? > Polling for data is fine also. It really depends upon what you are trying to do. For instance, if you require x bytes before reading, you can start polling after data is available. If you read on the same thread as your GUI and are waiting for data in a read, the results may be less than desirable. Java programming is 'usually' event driven rather than polling based. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sat Aug 16 20:10:39 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 22:10:39 -0400 Subject: [Rxtx] Using SerialPortEvent? In-Reply-To: References: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Message-ID: <3E495D4C-BB28-4845-A6AB-984C9A826BDF@sympatico.ca> On 16-Aug-08, at 21:41 , Trent Jarvi wrote: > On Sat, 16 Aug 2008, Andre-John Mas wrote: > >> Hi, >> >> Could someone tell me how I should be using the SerialPortEvent? Am I >> meant to be waiting for data and then simply reading from the >> inputstream? If this is the case why no just block on an inputstream >> read? >> > > Polling for data is fine also. It really depends upon what you are > trying to do. For instance, if you require x bytes before reading, > you can start polling after data is available. If you read on the > same thread as your GUI and are waiting for data in a read, the > results may be less than desirable. > > Java programming is 'usually' event driven rather than polling based. Sounds good. I thought I would use this opportunity to provide a event based version of the TwoWaySerialComm example. Could you just validate it before I add it to the Wiki: package ajmas74.experimental; import gnu.io.CommPort; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; import gnu.io.SerialPortEvent; import gnu.io.SerialPortEventListener; import java.io.IOException; import java.io.InputStream; import java.io.OutputStream; /** * This version of the TwoWaySerialComm example makes use of the * SerialPortEventListener to avoid polling. * * @author ajmas * */ public class TwoWaySerialComm { public TwoWaySerialComm() { super(); } void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { CommPort commPort = portIdentifier.open(this.getClass().getName(),2000); if ( commPort instanceof SerialPort ) { SerialPort serialPort = (SerialPort) commPort; serialPort .setSerialPortParams (57600 ,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); (new Thread(new SerialWriter(out))).start(); serialPort.addEventListener(new SerialReader(in)); } else { System.out.println("Error: Only serial ports are handled by this example."); } } } /** * Handles the input coming from the serial port. A new line character * is treated as the end of a block in this example. */ public static class SerialReader implements SerialPortEventListener { private InputStream in; private byte[] buffer = new byte[1024]; public SerialReader ( InputStream in ) { this.in = in; } public void serialEvent(SerialPortEvent arg0) { int data; try { int len = 0; while ( ( data = in.read()) > -1 ) { if ( data != '\n' ) { break; } buffer[len++] = (byte) data; } System.out.print(new String(buffer,0,len)); } catch ( IOException e ) { e.printStackTrace(); System.exit(-1); } } } /** */ public static class SerialWriter implements Runnable { OutputStream out; public SerialWriter ( OutputStream out ) { this.out = out; } public void run () { try { int c = 0; while ( ( c = System.in.read()) > -1 ) { this.out.write(c); } } catch ( IOException e ) { e.printStackTrace(); System.exit(-1); } } } public static void main ( String[] args ) { try { (new TwoWaySerialComm()).connect("COM3"); } catch ( Exception e ) { e.printStackTrace(); } } } From lfarkas at lfarkas.org Tue Aug 19 07:32:59 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Tue, 19 Aug 2008 15:32:59 +0200 Subject: [Rxtx] JNI or CNI Message-ID: <48AACB8B.9060606@lfarkas.org> hi, what is the current recommended way to rxtx on linux JNI or it's better to use CNI? is the CNI version fully functional and the same level as the JNI? i currently try to make a rhel/centos/fedora rpm for rxtx but has many problems with the standard dir structure. yours. -- Levente "Si vis pacem para bellum!" From lfarkas at lfarkas.org Tue Aug 19 08:47:34 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Tue, 19 Aug 2008 16:47:34 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel Message-ID: <48AADD06.7040809@lfarkas.org> hi, newer or not so newer linux kernel do not contain the UTS_RELEASE so the current rxtx is not compile on the latest kernels. even if it's commented out in the cvs configure there are other places. i attcahed a patch which fix it (or at least doesn't cause error at non-debug build). ps. is there any plan to the new 2.1-8 release in the near future? there are many changes (at least the license change in all file and in this case create a diff is very difficult)? the latest release more then 2 years old:-( -- Levente "Si vis pacem para bellum!" -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-2.1-uts.patch Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080819/ab5d38ac/attachment-0015.pl From ajmas at sympatico.ca Tue Aug 19 16:21:53 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 19 Aug 2008 18:21:53 -0400 Subject: [Rxtx] Event based example Message-ID: <24735BFB-B088-4B84-8173-FE98DF63B12F@sympatico.ca> Hi, I have just posted an example of using SerialPortEventListener in the Wiki: http://rxtx.qbang.org/wiki/index.php/Event_Based_Two_Way_Communication If you see any issues please could you let me know, or makes the changes. Andre From Martin.Oberhuber at windriver.com Fri Aug 22 04:02:24 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 22 Aug 2008 12:02:24 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <48AADD06.7040809@lfarkas.org> References: <48AADD06.7040809@lfarkas.org> Message-ID: <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> Farkas, there are indeed efforts to get a new RXTX release out the door. Your experience as a package maintainer would likely be helpful during these efforts, since I'd think it makes sense to keep the patches minimal that you must make to have the source compile in your environment. What are the things that you find problematic, apart from the UTS thing that you have mentioned before? What is the timing that you have in mind for your package? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Farkas Levente > Sent: Tuesday, August 19, 2008 4:48 PM > To: rxtx at qbang.org > Subject: [Rxtx] UTS_RELEASE not defined in newer kernel > > hi, > newer or not so newer linux kernel do not contain the > UTS_RELEASE so the > current rxtx is not compile on the latest kernels. even if it's > commented out in the cvs configure there are other places. > i attcahed a patch which fix it (or at least doesn't cause error at > non-debug build). > > ps. is there any plan to the new 2.1-8 release in the near > future? there > are many changes (at least the license change in all file and in this > case create a diff is very difficult)? the latest release more then 2 > years old:-( > > -- > Levente "Si vis pacem para bellum!" > From lfarkas at lfarkas.org Fri Aug 22 04:36:26 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Fri, 22 Aug 2008 12:36:26 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> References: <48AADD06.7040809@lfarkas.org> <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> Message-ID: <48AE96AA.6090505@lfarkas.org> hi, the packages already build for fedora-9 and centos-5 and here: http://www.lfarkas.org/linux/packages/ what i've to patch, the UTS, the configure script, but it's already fixed in the cvs (in another way) and the loadlibrary. the reasons for last one can be found here: https://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_files_that_use_JNI after we test it i'd like to add these packages to fedora and epel main repository (that's why it's be useful a new release after 2 years:-) imho versions are cheap and why not just release 2.1-8? the real code changes are minimal and if something critical bug found still can release 2.1-9:-) ps. and would be better to use simple number for version like 2.1-7 rather then 2.1-7v2. Oberhuber, Martin wrote: > Farkas, > > there are indeed efforts to get a new RXTX release out the > door. Your experience as a package maintainer would likely > be helpful during these efforts, since I'd think it makes > sense to keep the patches minimal that you must make to > have the source compile in your environment. > > What are the things that you find problematic, apart from > the UTS thing that you have mentioned before? > > What is the timing that you have in mind for your package? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >> On Behalf Of Farkas Levente >> Sent: Tuesday, August 19, 2008 4:48 PM >> To: rxtx at qbang.org >> Subject: [Rxtx] UTS_RELEASE not defined in newer kernel >> >> hi, >> newer or not so newer linux kernel do not contain the >> UTS_RELEASE so the >> current rxtx is not compile on the latest kernels. even if it's >> commented out in the cvs configure there are other places. >> i attcahed a patch which fix it (or at least doesn't cause error at >> non-debug build). >> >> ps. is there any plan to the new 2.1-8 release in the near >> future? there >> are many changes (at least the license change in all file and in this >> case create a diff is very difficult)? the latest release more then 2 >> years old:-( >> >> -- >> Levente "Si vis pacem para bellum!" >> -- Levente "Si vis pacem para bellum!" From tjarvi at qbang.org Fri Aug 22 18:50:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Aug 2008 18:50:32 -0600 (MDT) Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <48AE96AA.6090505@lfarkas.org> References: <48AADD06.7040809@lfarkas.org> <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> <48AE96AA.6090505@lfarkas.org> Message-ID: Hi Farkas, The v2 was simply the second build - no code changes. We are comming out with a new release shortly. I would encourage working with distros as you are. The building of rxtx turns out to be a bottle neck in quick releases. We do want stable releases that work for a year or more but I would have no problems with quicker cycles on developing work. I would have no problem working with someone that did builds that receive less testing more often but they do have to come out for multiple platforms from this end. Thanks for the links. On Fri, 22 Aug 2008, Farkas Levente wrote: > hi, > the packages already build for fedora-9 and centos-5 and here: > http://www.lfarkas.org/linux/packages/ > what i've to patch, the UTS, the configure script, but it's already > fixed in the cvs (in another way) and the loadlibrary. the reasons for > last one can be found here: > https://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_files_that_use_JNI > after we test it i'd like to add these packages to fedora and epel main > repository (that's why it's be useful a new release after 2 years:-) > imho versions are cheap and why not just release 2.1-8? the real code > changes are minimal and if something critical bug found still can > release 2.1-9:-) > > ps. and would be better to use simple number for version like 2.1-7 > rather then 2.1-7v2. > > Oberhuber, Martin wrote: >> Farkas, >> >> there are indeed efforts to get a new RXTX release out the >> door. Your experience as a package maintainer would likely >> be helpful during these efforts, since I'd think it makes >> sense to keep the patches minimal that you must make to >> have the source compile in your environment. >> >> What are the things that you find problematic, apart from >> the UTS thing that you have mentioned before? >> >> What is the timing that you have in mind for your package? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >>> On Behalf Of Farkas Levente >>> Sent: Tuesday, August 19, 2008 4:48 PM >>> To: rxtx at qbang.org >>> Subject: [Rxtx] UTS_RELEASE not defined in newer kernel >>> >>> hi, >>> newer or not so newer linux kernel do not contain the >>> UTS_RELEASE so the >>> current rxtx is not compile on the latest kernels. even if it's >>> commented out in the cvs configure there are other places. >>> i attcahed a patch which fix it (or at least doesn't cause error at >>> non-debug build). >>> >>> ps. is there any plan to the new 2.1-8 release in the near >>> future? there >>> are many changes (at least the license change in all file and in this >>> case create a diff is very difficult)? the latest release more then 2 >>> years old:-( >>> >>> -- >>> Levente "Si vis pacem para bellum!" >>> > > > From andy at triera.net Sat Aug 23 15:17:44 2008 From: andy at triera.net (Andy Rozman) Date: Sat, 23 Aug 2008 21:17:44 +0000 Subject: [Rxtx] port not identified on FreeBSD In-Reply-To: References: Message-ID: <48B07E78.2030306@triera.net> Hi ! I have one small problem... I have started using FreeBSD in last few days and I have come accross a problem with rxtx on FreeBSD. I am using usb-to-serial converter, which is identified under FreeBSD without problem as ucom0, and creates link under /dev called ttyU0, which is correct way to be done under FreeBSD (if device would be unidentified it would be called ugen0 - as usb generic). Problem is that I say to rxtx to get my all serial ports this one is not among them. Which names are permissable under linux-like implementations? Which will be accepted as serial ports? Andy From tjarvi at qbang.org Sat Aug 23 13:57:45 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 23 Aug 2008 13:57:45 -0600 (MDT) Subject: [Rxtx] port not identified on FreeBSD In-Reply-To: <48B07E78.2030306@triera.net> References: <48B07E78.2030306@triera.net> Message-ID: On Sat, 23 Aug 2008, Andy Rozman wrote: > Hi ! > > I have one small problem... I have started using FreeBSD in last few > days and I have come accross a problem with rxtx on FreeBSD. > > I am using usb-to-serial converter, which is identified under FreeBSD > without problem as ucom0, and creates link under /dev called > ttyU0, which is correct way to be done under FreeBSD (if device would be > unidentified it would be called ugen0 - as usb generic). Problem is that > I say to rxtx to get my all serial ports this one is not among them. > Which names are permissable under linux-like implementations? Which will > be accepted as serial ports? > > Andy > Thanks Andy! We will add ttyU* to FreeBSD. For now you can use properties to enable the port. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting#How_does_rxtx_detect_ports.3F__Can_I_override_it.3F The fix: diff -u -r1.16.2.59 RXTXCommDriver.java --- RXTXCommDriver.java 18 Nov 2007 22:32:41 -0000 1.16.2.59 +++ RXTXCommDriver.java 23 Aug 2008 19:55:25 -0000 @@ -644,6 +644,7 @@ { String[] Temp = { "ttyd", //general purpose serial ports + "ttyU", //general purpose USB serial ports "cuaa", //dialout serial ports "ttyA", //Specialix SI/XIO dialin ports "cuaA", //Specialix SI/XIO dialout ports -- Trent Jarvi tjarvi at qbang.org From rick_knight at rlknight.com Mon Aug 4 13:25:10 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Mon, 04 Aug 2008 12:25:10 -0700 Subject: [Rxtx] Sun's Comm API? Message-ID: <48975796.4010600@rlknight.com> I have an application that requires the javax compatible version of RXTX and Sun's comm api. I've been able to download and extract the version of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api anywhere. Can someone tell me where I can find it? Or maybe send me a copy? Also, when I try to build RXTX, configure and make complete successfully but make install failes with this error libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 I've never come accross this error before. How can I get past it? Thanks, Rick From bboyes at systronix.com Mon Aug 4 19:10:01 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:10:01 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48975796.4010600@rlknight.com> References: <48975796.4010600@rlknight.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/cb9c6167/attachment-0031.html From bboyes at systronix.com Mon Aug 4 19:12:37 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:12:37 -0600 Subject: [Rxtx] Towards an RXTX release - CSR BT/USB chipset In-Reply-To: <488FB7E7.8000802@gmail.com> References: <460801A4097E3D4CA04CC64EE648584806C56CF0@ism-mail03.corp.ad.wrs.com> <13557-75390@sneakemail.com> <20980-23424@sneakemail.com> <488FB7E7.8000802@gmail.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/52236088/attachment-0031.html From tjarvi at qbang.org Mon Aug 4 19:42:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 19:42:21 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: On Mon, 4 Aug 2008, Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: > I have an application that requires the javax compatible > version of RXTX > and Sun's comm api. I've been able to download and extract > the version > of RXTX that I need (2.0-7pre2) but I can't find Sun's camm > api > anywhere. Can someone tell me where I can find it? Or maybe > send me a > > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm port > support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have just > a ZIP with only the .class JAR file - no source or docs), has a readme > with these comments: > > This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release.? The 2.0.3 release itself is > no longer distributed.? comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project.? The RxTx project (http://www.rxtx.org ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org) was opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support.? Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins.? Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > ? > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > I hope that is helpful! > It would be nice to work with Sun to resolve those longstanding issues. But it may not be practical unless the process goes as fast and painless as the grandfathering of commapi did. Another option may be the old kaffe extensions that moved to gnu classpathx. These don't have the native libraries but should provide the 2.0 interface and the javax.comm.properties mechansim for SPI. http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Mon Aug 4 20:23:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Mon, 04 Aug 2008 20:23:57 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4897B9BD.5070809@ergotech.com> Has there been any work/would it be possible, to layer a javacomm look-alike on top of the GNU code? The goal is not to move the javax code forward, but to emulate the "legacy" javax packages for people who still need this. Jim Trent Jarvi wrote: > On Mon, 4 Aug 2008, Bruce Boyes wrote: > >> At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible >> version of RXTX >> and Sun's comm api. I've been able to download and extract >> the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm >> api >> anywhere. Can someone tell me where I can find it? Or maybe >> send me a >> >> >> javaxcomm has had a sort of on-again off-again history. The windoze >> version has been languishing for years (literally) but there are newer >> versions for other OS's. >> >> We try to keep links on one of our help pages current: >> http://www.practicalembeddedjava.com/tools/javatools_list.html >> which gets you to here: >> http://java.sun.com/products/javacomm/ >> where it says in fact they no longer even support Windows and Mac: >> "Implementations of the API are currently available for Solaris SPARC, >> Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so >> someone could support it. But I guess that's part of the reason RXTX >> exists! >> >> So one of Sun's own products, SunSPOT, has to use RXTX to get comm port >> support. >> >> The version we use is 2.0 from 11/15/1998. I have posted it on our >> website, which is within the terms of the license agreement contained >> therein (as I understand it). >> >> The last version of javaxcomm for Windows, 2.0.3, (for which I have just >> a ZIP with only the .class JAR file - no source or docs), has a readme >> with these comments: >> >> This distribution contains the comm.jar file original part >> of the COMMAPI 2.0.3 release. The 2.0.3 release itself is >> no longer distributed. comm.jar, which contains the comm >> API java class files (eg. Sun's binary implementation of the >> interface classes), is being made available, unsupported, >> with no obligation to fix bugs, at the request of the RXTX >> project. The RxTx project (http://www.rxtx.org ), uses the >> comm.jar class files, but provides their own native library >> components to provide support for other platforms. >> >> The 2.0.3 comm.jar is being provided in this way because >> as of COMMAPI 3.x, the java binary implementation forked and >> became incompatible with the RxTx project's native code. >> Due to the lack of a clear business case, and to resource >> constraints, no additional resources are being >> provided to provide an alternative engineering solution >> at the time of writing. >> >> RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: >> >> Ultimately the COMMAPI would be better served if a Java >> Community Process JSR (http://www.jcp.org) was opened and >> the COMMAPI was rearchitected to provide a more pluggable >> framework to improve cross-platform support. Such an >> architecture would embody a better defined and better >> documented SPI interface, including a way for comm. ports >> to be revealed to the client application through the API >> via platform-aware plugins. Similarly, native code used >> to access comm port in general could be handled more >> flexibly using a plugin model, whereby on any platform, >> multiple native modules could be in use simultaneously. >> >> Since there are now various ways serial ports can be implemented >> and accessed, modular comm. port JNI native libraries would be >> of benefit insofar as removing the burden of over-generalization >> from any single native component, or inversely, by relieving the >> implicit constraint that comm. drivers be accessed only via a >> monolithic mechanism, such as the UNIX vnode interface. >> >> paul.klissner at sun.com >> 6/10/06 >> >> I hope that is helpful! >> > > It would be nice to work with Sun to resolve those longstanding issues. > But it may not be practical unless the process goes as fast and painless > as the grandfathering of commapi did. > > Another option may be the old kaffe extensions that moved to gnu > classpathx. These don't have the native libraries but should provide > the 2.0 interface and the javax.comm.properties mechansim for SPI. > > http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Mon Aug 4 21:09:15 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 21:09:15 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? Message-ID: Hi Jim, I will not step into the javax.comm namespace without Sun's explicite permission. I fully understand the pain point you are trying to address. In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm Linux) - which remains an integral part of rxtx. At the time it was a win for Sun and rxtx. The Sun commapi license is/was fairly clear that rxtx should not step into that namespace. It made sense as Sun was active in that space and rxtx may go into another namespace - it was an experiment in working with Sun. This may sound silly looking at something that happened almost 10 years ago. In a community of respect which Sun helped create, there is no question about what to do. I hope eventually Sun will step up and do a right thing too. I agree that this is hurting the API more than helping it. There are also questions about how to replace the API in the long term which includes HID support which isn't going well so far. Others that can't even look at Sun's javax.comm today and can look at Kaffe's contribution to classpathx can easily work around such restrictions. On Mon, 4 Aug 2008, Jim Redman wrote: > Has there been any work/would it be possible, to layer a javacomm > look-alike on top of the GNU code? > > The goal is not to move the javax code forward, but to emulate the > "legacy" javax packages for people who still need this. > > Jim > > Trent Jarvi wrote: >> >> It would be nice to work with Sun to resolve those longstanding issues. >> But it may not be practical unless the process goes as fast and painless >> as the grandfathering of commapi did. >> >> Another option may be the old kaffe extensions that moved to gnu >> classpathx. These don't have the native libraries but should provide >> the 2.0 interface and the javax.comm.properties mechansim for SPI. >> >> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From florianmanschwetus at gmx.de Tue Aug 5 05:04:46 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 13:04:46 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: References: <48971C1F.9020806@gmx.de> Message-ID: <489833CE.1040801@gmx.de> Just look at sendCommand in this method I have to place a Thread.sleep(20) after each byte send to get working. Even the event based receive doesn't work fine but this could be may stupidness. The specifikation document (it is on the last pages of the manual) for the beamer could be found on: http://www.optoma.co.uk/support.aspx Florian Manschwetus Trent Jarvi schrieb: > > Hi Florian > > Sorry for the top post in advance. I worry you may not see my answer > under all your code :) > > I have not received this email before. This is 500k of code which I > don't have time to read. I can spend about 5 min on each hobby email > and still get to work in the morning. I have a couple suggestions for > how to get an answer. > > First, cut out your comments and extra code so you can demonstrate the > question (I might even glance and see what is wrong then). Don't go for > a working final product. Isolate the problem using a simple program and > then ask with that as an example. If I did what you just did, I'd have > to post 3/4 of a million lines of code :) > > Second, join the rxtx mail-list and ask there. This will give you 100x > more eyes. I'll also read and try to follow. > > -- > taj > > > > On Mon, 4 Aug 2008, Florian Manschwetus wrote: > >> It could be that my university account is blocked by filters so >> resending from here. >> >> >> Topic is to control Optoma HD80 beamer using rs232 serial chat. >> This code is able to detect power state and switch the beamer on / off. >> connected is the beamer using a digitus usb 2.0 serial adapter with an >> FT232 USB-Serial adapter the systems architecture is amd64. >> >> Please take a look in the sendCommand routine i have to place theire >> those Thread.sleep to get it working. >> Now the question is this correct or is there a better way to get this >> working correctly? >> >> In the javadoc coming with the install i found this: >> setBaudBase >> >> public boolean setBaudBase(int BaudBase) >> throws UnsupportedCommOperationException, >> java.io.IOException >> >> Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 >> before using. >> >> could this explain the error? >> I attached my java source and the protocol description for the beamer >> (available on vendor website). >> >> thx, >> Florian Manschwetus >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: TestRS232.java Type: text/x-java Size: 9143 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0062.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0063.bin From michael.erskine at ketech.com Tue Aug 5 05:53:49 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Tue, 5 Aug 2008 12:53:49 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489833CE.1040801@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> > Just look at sendCommand in this method I have to place a > Thread.sleep(20) after each byte send to get working. Even the event > based receive doesn't work fine but this could be may stupidness. Hi Florian, Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. Regards, Michael Erskine. From florianmanschwetus at gmx.de Tue Aug 5 07:28:15 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:28:15 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> Message-ID: <4898556F.8000208@gmx.de> Michael Erskine schrieb: >> Just look at sendCommand in this method I have to place a >> Thread.sleep(20) after each byte send to get working. Even the event >> based receive doesn't work fine but this could be may stupidness. > > Hi Florian, > > Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. > > Regards, > Michael Erskine. > Ok, sounds fine for the receiving problem. But why i have to wait after each byte when sending a command squence? (the for loop in send command) Florian > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/284f350c/attachment-0030.bin From florianmanschwetus at gmx.de Tue Aug 5 07:44:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:44:14 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <4898592E.2020908@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >>> Just look at sendCommand in this method I have to place a >>> Thread.sleep(20) after each byte send to get working. Even the event >>> based receive doesn't work fine but this could be may stupidness. >> >> Hi Florian, >> >> Yes, naturally you'll have to wait for a response from the other end. >> Why not wait for notification from the event thread perhaps using a >> BlockingDeque rather than your LinkedList. Generally I >> try to decouple all input and output streams: in your case your >> application is operating synchronously like the "expect" program >> (http://expect.nist.gov/) so waits (or timeouts) will need to be >> factored in. >> >> Regards, >> Michael Erskine. >> > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) > > Florian Furthermore there is this basic baud with this confusing javadoc entry: public boolean setBaudBase(int BaudBase) throws UnsupportedCommOperationException, java.io.IOException Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 before using. maybe this could explain something Florian >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/006c7425/attachment-0030.bin From jredman at ergotech.com Tue Aug 5 09:13:36 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 05 Aug 2008 09:13:36 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: Message-ID: <48986E20.3060104@ergotech.com> Trent, So two issues: 1) Technically I'm still not sure how easy/practical a layer would be. The problems are always classes like listeners, and wrapping returns of gnu.io classes. I really see it as a "delegate" type of concept. Any thoughts or ideas of the practicality of this approach? The idea is not to modify RXTX. 2) Javax. The javax namespace does seem to be in widespread use outside of Sun (the same is true for the java namespace). The classpath extensions, or some other location, should be interested in a JavaComm implementation even if it does have dependencies on RXTX. Would you have any philosophical objection to an approach like that? Of course, I suspect it might be better if someone with that authority at Sun would admit that the javax namespace is already in the wild and that there is no problem with it being used within RXTX. Jim Trent Jarvi wrote: > Hi Jim, > > I will not step into the javax.comm namespace without Sun's explicite > permission. I fully understand the pain point you are trying to address. > > In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm > Linux) - which remains an integral part of rxtx. At the time it was a win for > Sun and rxtx. > > The Sun commapi license is/was fairly clear that rxtx should not step into that > namespace. It made sense as Sun was active in that space and rxtx may go into > another namespace - it was an experiment in working with Sun. > > This may sound silly looking at something that happened almost 10 years ago. > In a community of respect which Sun helped create, there is no question about > what to do. I hope eventually Sun will step up and do a right thing too. > > I agree that this is hurting the API more than helping it. There are also > questions about how to replace the API in the long term which includes HID > support which isn't going well so far. > > Others that can't even look at Sun's javax.comm today and can look at Kaffe's > contribution to classpathx can easily work around such restrictions. > > On Mon, 4 Aug 2008, Jim Redman wrote: > >> Has there been any work/would it be possible, to layer a javacomm >> look-alike on top of the GNU code? >> >> The goal is not to move the javax code forward, but to emulate the >> "legacy" javax packages for people who still need this. >> >> Jim >> >> Trent Jarvi wrote: >>> It would be nice to work with Sun to resolve those longstanding issues. >>> But it may not be practical unless the process goes as fast and painless >>> as the grandfathering of commapi did. >>> >>> Another option may be the old kaffe extensions that moved to gnu >>> classpathx. These don't have the native libraries but should provide >>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>> >>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From sandeep at genevasoftech.com Tue Aug 5 11:18:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Tue, 05 Aug 2008 22:48:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <48988B6C.5080409@genevasoftech.com> Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. *-- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/ad20f1cb/attachment-0030.html From Martin.Oberhuber at windriver.com Tue Aug 5 13:30:17 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Tue, 5 Aug 2008 21:30:17 +0200 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Sandeep, shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on Sol7 but I've successfully run it on Sol9 and Sol10. Or is your request really about a native 64bit variant? I'm afraid that then you're out of luck since I think that quite a bit of RXTX is not yet ready for 64 bit. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Sandeep Kumar K Sent: Tuesday, August 05, 2008 7:19 PM To: rxtx at qbang.org Subject: [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so for Solaris 9 Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. -- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/81b7f988/attachment-0030.html From tjarvi at qbang.org Tue Aug 5 22:38:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 22:38:34 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 5 Aug 2008, Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built > on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid that > then > you're out of luck since I think that quite a bit of RXTX is not yet > ready > for 64 bit. > While rxtx-2.1-7 probably has problems, The CVS code should be OK for 64 bit Solaris. If it isn't, let me know and I'll find which patch is missing. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Aug 5 23:13:00 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 23:13:00 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48986E20.3060104@ergotech.com> References: <48986E20.3060104@ergotech.com> Message-ID: On Tue, 5 Aug 2008, Jim Redman wrote: > Trent, > > So two issues: > > 1) Technically I'm still not sure how easy/practical a layer would be. The > problems are always classes like listeners, and wrapping returns of gnu.io > classes. I really see it as a "delegate" type of concept. Any thoughts or > ideas of the practicality of this approach? The idea is not to modify RXTX. I have not put too much thought into this. I assume you want what rxtx 2.0 provided to tie into javax.comm implementations. More classes could be added to rxtx 2.1-7 for SPI support. Maintaining rxtx-2.0 could also be handed to someone if they like. > > 2) Javax. The javax namespace does seem to be in widespread use outside of > Sun (the same is true for the java namespace). The classpath extensions, or > some other location, should be interested in a JavaComm implementation even > if it does have dependencies on RXTX. Would you have any philosophical > objection to an approach like that? > No problems. Classpathx would be a possible place to do it. I'd suggest thinking twice about what this involves in practical terms. You would be wanting to revive the 2.0 API while Sun is at 3.0 and grandfathering the JSR. This undermines the main reason (established api) for using the javax.comm namespace and does not leave such a project in a good position. The only win I see here is maintaining support for applications that can't migrate namespaces. Not that that isn't important. At some point it is going to be less work to just edit the bytecode :) Such a javax.comm effort would also be signing up new projects that decided to use the work up for concerns they probably will not understand or expect. That probably isn't a good path to facilitate for new projects at this time. We will put a good faith effort to work well with others but keep in mind the project has limited bandwidth for such efforts. > Of course, I suspect it might be better if someone with that authority at Sun > would admit that the javax namespace is already in the wild and that there is > no problem with it being used within RXTX. > > Jim > > Trent Jarvi wrote: >> Hi Jim, >> >> I will not step into the javax.comm namespace without Sun's explicite >> permission. I fully understand the pain point you are trying to address. >> >> In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java >> Comm Linux) - which remains an integral part of rxtx. At the time it was a >> win for Sun and rxtx. >> >> The Sun commapi license is/was fairly clear that rxtx should not step into >> that namespace. It made sense as Sun was active in that space and rxtx may >> go into another namespace - it was an experiment in working with Sun. >> >> This may sound silly looking at something that happened almost 10 years >> ago. In a community of respect which Sun helped create, there is no >> question about what to do. I hope eventually Sun will step up and do a >> right thing too. >> >> I agree that this is hurting the API more than helping it. There are also >> questions about how to replace the API in the long term which includes HID >> support which isn't going well so far. >> >> Others that can't even look at Sun's javax.comm today and can look at >> Kaffe's contribution to classpathx can easily work around such >> restrictions. >> >> On Mon, 4 Aug 2008, Jim Redman wrote: >> >>> Has there been any work/would it be possible, to layer a javacomm >>> look-alike on top of the GNU code? >>> >>> The goal is not to move the javax code forward, but to emulate the >>> "legacy" javax packages for people who still need this. >>> >>> Jim >>> >>> Trent Jarvi wrote: >>>> It would be nice to work with Sun to resolve those longstanding issues. >>>> But it may not be practical unless the process goes as fast and painless >>>> as the grandfathering of commapi did. >>>> >>>> Another option may be the old kaffe extensions that moved to gnu >>>> classpathx. These don't have the native libraries but should provide >>>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>>> >>>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From sandeep at genevasoftech.com Wed Aug 6 00:03:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Wed, 06 Aug 2008 11:33:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: <48993EB8.30107@genevasoftech.com> Thank you Mr. Martin for your suggestion. The native file which is given in rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am getting the following error . Any suggestions to solve this issue. I am using Solaris SPARC 64 bit machine. ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) thrown while loading gnu.io.RXTXCommDriver Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(Unknown Source) at java.lang.ClassLoader.loadLibrary(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) at com.ReadFromModem.main(ReadFromModem.java:84) * * *Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid > that then > you're out of luck since I think that quite a bit of RXTX is not yet ready > for 64 bit. > > Cheers, > -- > *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > ------------------------------------------------------------------------ > *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On > Behalf Of *Sandeep Kumar K > *Sent:* Tuesday, August 05, 2008 7:19 PM > *To:* rxtx at qbang.org > *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so > for Solaris 9 > > Hi, > > Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 > bit machine. The librxtxSerial.so given in website is for Solaris 8. > > *-- > > Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/1e920343/attachment-0030.html From tjarvi at qbang.org Wed Aug 6 00:21:42 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 00:21:42 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <48993EB8.30107@genevasoftech.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> <48993EB8.30107@genevasoftech.com> Message-ID: Hi Sandeep You may be out of luck unless you can compile the 2.1 src in CVS (requires gnu make and gcc). But you could try the ToyBox(R)(TM) which is a collection of WiLdLy untested cross compiled 2.1-7 binaries covering everything from the ibm z series to embeded arm/ppc. To give an idea how poorly these are tested, I don't even know if z series machines have a serial port. ftp://www.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Solaris They should at least match the binary types. Actually, I think if you use the rxtx jar from CVS with that file, it should 'work' as the fix for 64 bits was in java not the native code. You could just cd rxtx*/src; javac *.java then jar -cf RXTXcomm.jar `find -name \*.class` to create the hybrid which will complain about version information a bit. On Wed, 6 Aug 2008, Sandeep Kumar K wrote: > Thank you Mr. Martin for your suggestion. The native file which is given in > rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am > getting the following error . > Any suggestions to solve this issue. > I am using Solaris SPARC 64 bit machine. > > ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar > java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 > (Possible cause: architecture word > width mismatch) thrown while loading gnu.io.RXTXCommDriver > Exception in thread "main" java.lang.UnsatisfiedLinkError: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF > class: ELFCLASS64 (Possible cause: > architecture word width mismatch) > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(Unknown Source) > at java.lang.ClassLoader.loadLibrary(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > at com.ReadFromModem.main(ReadFromModem.java:84) > > * > * > > *Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > > > Oberhuber, Martin wrote: >> Sandeep, >> shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse >> variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on >> Sol7 but I've successfully run it on Sol9 and Sol10. >> Or is your request really about a native 64bit variant? I'm afraid that >> then >> you're out of luck since I think that quite a bit of RXTX is not yet ready >> for 64 bit. >> Cheers, >> -- >> *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> ------------------------------------------------------------------------ >> *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On >> Behalf Of *Sandeep Kumar K >> *Sent:* Tuesday, August 05, 2008 7:19 PM >> *To:* rxtx at qbang.org >> *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so >> for Solaris 9 >> >> Hi, >> >> Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 >> bit machine. The librxtxSerial.so given in website is for Solaris 8. >> >> *-- >> Thanks & Regards >> >> Sandeep Kumar K >> Sr. Software Engineer >> Geneva Software Technologies >> Whitefield, Bangalore >> Mob : 9880193454* >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> From michael.erskine at ketech.com Wed Aug 6 01:39:28 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 6 Aug 2008 08:39:28 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Florian Manschwetus wrote: > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) Hi Florian, I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. Regards, Michael Erskine. From florianmanschwetus at gmx.de Wed Aug 6 02:53:16 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 06 Aug 2008 10:53:16 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Message-ID: <4899667C.6010706@gmx.de> Michael Erskine schrieb: > Florian Manschwetus wrote: >> Ok, sounds fine for the receiving problem. >> But why i have to wait after each byte when sending a command squence? >> (the for loop in send command) > > Hi Florian, > I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. > > Regards, > Michael Erskine. > correct with a terminal on the other end it works, my idea was that this basic baud has some influence. Could some one explain what it is for? Florian > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/c2b4fa84/attachment-0030.bin From rick_knight at rlknight.com Wed Aug 6 13:01:07 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:01:07 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F4F3.3020707@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > I have an application (Readerware) that uses RXTX with Javax to access the serial port. This used to work fine under previous Linux' and Java, but something has changed, I assume with Java itself , that is causing the application to fail with a link error. The application is not able to find librxtxSerialParallel.so. RXTX supplies librxtxSerial.so and librxtxParallel.so, but not librxtxSerialParallel.so. Where can I get librxtxSerialParallel.so, or do I need it? Is something else causing the lib to not be found? Thanks, Rick Knight From rick_knight at rlknight.com Wed Aug 6 13:17:55 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:17:55 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F8E3.5060400@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Thanks for the reply. The developer of the app I'm trying to use (Readerware) has sent me a copy of the comm.api and I've copied the library (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar into the proper places. When I try to run the application, I get this error... Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: /usr/lib/libSolarisSerialParallel.so: /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not little-endian (Possible cause: endianness mismatch) Caught java.lang.UnsatisfiedLinkError: com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I while loading driver com.sun.comm.SolarisDriver Is there a way around this error? Thanks again, Rick Knight From jlar310 at gmail.com Wed Aug 6 13:37:42 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 14:37:42 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899F8E3.5060400@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > The developer of the app I'm trying to use (Readerware) has sent me a > copy of the comm.api and I've copied the library > (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar > into the proper places. When I try to run the application, I get this > error... > > Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: > /usr/lib/libSolarisSerialParallel.so: > /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not > little-endian (Possible cause: endianness mismatch) > Caught java.lang.UnsatisfiedLinkError: > com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I > > while loading driver com.sun.comm.SolarisDriver > > Is there a way around this error? What host OS are you running? From your original post it looks like 32 bit Linux. The libSolarisSerialParallel.so file is for Sun Solaris and will vary depending on the underlying hardware architecture as well. Sorry for the double post Rick, but I failed to send this to the list the first time... -- Jeff From rick_knight at rlknight.com Wed Aug 6 13:44:29 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:44:29 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: <4899FF1D.9030504@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > > >> The developer of the app I'm trying to use (Readerware) has sent me a >> copy of the comm.api and I've copied the library >> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >> into the proper places. When I try to run the application, I get this >> error... >> >> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >> /usr/lib/libSolarisSerialParallel.so: >> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >> little-endian (Possible cause: endianness mismatch) >> Caught java.lang.UnsatisfiedLinkError: >> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >> >> while loading driver com.sun.comm.SolarisDriver >> >> Is there a way around this error? >> > > What host OS are you running? From your original post it looks like 32 > bit Linux. > > The libSolarisSerialParallel.so file is for Sun Solaris and will vary > depending on the underlying hardware architecture as well. > > I'm running Kubuntu Linux (debian based). It's 32 bit. Rick Knight From jlar310 at gmail.com Wed Aug 6 15:33:23 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 16:33:23 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > I don't think Sun did binary libraries for Linux in the 2.0 version. Can someone with more historical experience than I confirm that? I recently tried to port a Comm API application from Solaris sparc to Linux x86 and likewise could not get my hands on the binary libraries. I eventually just re-wrote the code to use the gnu namespace packages and rxtx 2.1. What I don't understand is why your application vendor does not provide everything you need to run their software. FYI: I have librxtxParallel.so and librxtxSerial.so installed at JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is /usr/java/default which is actually a softlink to /usr/java/jre1.6.0_05. -- Jeff From defiantlew at yahoo.com.au Wed Aug 6 16:29:33 2008 From: defiantlew at yahoo.com.au (Lew L) Date: Thu, 7 Aug 2008 08:29:33 +1000 Subject: [Rxtx] Sun's Comm API Documentation References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> Message-ID: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> As a matter of interest is the Sun Comm API documentation available somewhere? I have tried the Sun site but it seems to have been removed. Unless I have missed the documentation for RXTX? I javadocced the RXTX source but information (to me) is minimal. Somewhere I got the impression that the Sun Comm API docs is, or was, compatible with RXTX, what is the best docs to use in conjuntion with RXTX and where may the be available? Cheers Lew From rick_knight at rlknight.com Wed Aug 6 17:18:33 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:18:33 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A3149.4050306@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff I'm not sure if I posted this here or not, but when I try to build RXTX from source I get this install error... make all-am make[1]: Entering directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' make[1]: Nothing to be done for `all-am'. make[1]: Leaving directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 Can you tell me how to get past this error and get RXTX built and installed? Thanks, Rick From bboyes at systronix.com Wed Aug 6 17:40:12 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Wed, 06 Aug 2008 17:40:12 -0600 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: At 16:29 08/06/2008, Lew L wrote: >As a matter of interest is the Sun Comm API documentation available >somewhere? I have tried the Sun site but it seems to have been removed. It's in the file we have posted, link in prev email (sorry, in a huge hurry right now). Javadocs definitely there. >Unless I have missed the documentation for RXTX? I javadocced the RXTX >source but information (to me) is minimal. >Somewhere I got the impression that the Sun Comm API docs is, or was, >compatible with RXTX, what is the best docs to use in conjuntion with RXTX >and where may the be available? Yeah, this is one of my concerns/beefs. There is little documentation for RXTX and it isn't just the same as javaxcomm. I would be willing to help out writing docs for RXTX! Yes really... esp if we can fix the Bluetooth issues. best regards Bruce >Cheers >Lew > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx ------- WWW.SYSTRONIX.COM ---------- Real embedded Java and much more +1-801-534-1017 Salt Lake City, USA From rick_knight at rlknight.com Wed Aug 6 17:54:08 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:54:08 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A39A0.2090309@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff, I would like for my vendor to switch to rxtx 2.1. It would make things much easier for me. I'm not sure why he's still using the javax compatible code. He's a small operation. Re-writing the code to use gnu namespace sounds like a major overhaul. Was it? Thanks, Rick From tjarvi at qbang.org Wed Aug 6 21:35:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:35:12 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: >> >>> Jeff wrote: >>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>>> >>>> >>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things > much easier for me. I'm not sure why he's still using the javax > compatible code. He's a small operation. Re-writing the code to use gnu > namespace sounds like a major overhaul. Was it? > Hi Jeff, The changes are fairly mechanical. Imports need to change and any explicite use of the namespace needs to change such as catching an exception. The following script was made for maintaining rxtx 2.0 but can apply to other needs. It is in the contrib dir with rxtx source. #!/bin/sh # Don't use! :) # # Sat, 03 May 2003 16:45:08 Modifications from J?rg Weule # Create a ed-cmd for the change of one pattern # case $1 in gnu) X=g/javax_comm/s+javax_comm+gnu_io+g ;; javax) X=g/gnu_io/s+gnu_io+javax_comm+g ;; *) echo;echo;echo From the top rxtx directory run;echo;echo -e \\t./ChangePackage.sh gnu;echo -e \\t\\tor;echo -e \\t./ChangePackage.sh javax;echo;echo; exit 0 ;; esac # # ed will be used to keep the owner and mode of the files unchanged. # We have run the ed-script for the characters '.' '/' as well. # "tr _ $D" do the change. # find . -type f -a -print | grep -v $0 | (while read F ; do ( echo $X; echo $X| tr _ /; echo $X| tr _ .; echo w; echo q ) | ed $F 2>&1 >/dev/null done ) # # Now we do little changes at the Makefiles. Hope that all we need. # find . -name Makefile\* -a -print | (while read F ; do cat < References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: On Thu, 7 Aug 2008, Lew L wrote: > As a matter of interest is the Sun Comm API documentation available > somewhere? I have tried the Sun site but it seems to have been removed. > > Unless I have missed the documentation for RXTX? I javadocced the RXTX > source but information (to me) is minimal. > Somewhere I got the impression that the Sun Comm API docs is, or was, > compatible with RXTX, what is the best docs to use in conjuntion with RXTX > and where may the be available? > Hi Lew, The documentation on Sun's website is accurate. The changes that are problematic in 3.0 are on the backside which rxtx used to plug into. http://java.sun.com/products/javacomm/reference/api/index.html CommPortIdentifier may have some minor differences (judging by the authors notes). -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Aug 6 21:46:08 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:46:08 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > If javax.comm.properties is properly installed and you are using a 2.0 version of Sun's commapi with rxtx 2.0, you should not see the library attempt to load libSolarisSerialParallel.so. Sun CommAPI 3.0 will not work with any version of rxtx as it is hard coded to use the shared library. See the INSTALL file with rxtx-2.0 source for more help with the properties file. -- Trent Jarvi tjarvi at qbang.org From jlar310 at gmail.com Thu Aug 7 06:32:06 2008 From: jlar310 at gmail.com (Jeff) Date: Thu, 7 Aug 2008 07:32:06 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > Jeff wrote: >> >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >> wrote: >> >>> >>> Jeff wrote: >>> >>>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>> wrote: >>>> >>>> >>>> >>>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things much > easier for me. I'm not sure why he's still using the javax compatible code. > He's a small operation. Re-writing the code to use gnu namespace sounds like > a major overhaul. Was it? I found it quite easy. In fact, in order to accommodate the transition, I actually separated all of the code that deals directly with the Comm API or RXTX into a helper class. The helper class was then coded to use reflection to determine which library was available and then instantiate the necessary objects. No direct imports of either library are used. The main application just needs to get it's hands on the IO streams and need not deal directly with the libraries. Other programs may not be so simple... But this doesn't really help you unless your vendor forks over the source code... -- Jeff From rick_knight at rlknight.com Thu Aug 7 09:47:12 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Thu, 07 Aug 2008 08:47:12 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: <489B1900.10108@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >>> wrote: >>> >>> >>>> Jeff wrote: >>>> >>>> >>>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>>> copy of the comm.api and I've copied the library >>>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>>> into the proper places. When I try to run the application, I get this >>>>>> error... >>>>>> >>>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>>> /usr/lib/libSolarisSerialParallel.so: >>>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>>> little-endian (Possible cause: endianness mismatch) >>>>>> Caught java.lang.UnsatisfiedLinkError: >>>>>> >>>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>>> >>>>>> while loading driver com.sun.comm.SolarisDriver >>>>>> >>>>>> Is there a way around this error? >>>>>> >>>>>> >>>>>> >>>>> What host OS are you running? From your original post it looks like 32 >>>>> bit Linux. >>>>> >>>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>>> depending on the underlying hardware architecture as well. >>>>> >>>>> >>>>> >>>>> >>>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>>> >>>> >>>> >>> I don't think Sun did binary libraries for Linux in the 2.0 version. >>> Can someone with more historical experience than I confirm that? >>> >>> I recently tried to port a Comm API application from Solaris sparc to >>> Linux x86 and likewise could not get my hands on the binary libraries. >>> I eventually just re-wrote the code to use the gnu namespace packages >>> and rxtx 2.1. >>> >>> What I don't understand is why your application vendor does not >>> provide everything you need to run their software. >>> >>> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >>> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >>> /usr/java/default which is actually a softlink to >>> /usr/java/jre1.6.0_05. >>> >>> >>> >> Jeff, >> >> I would like for my vendor to switch to rxtx 2.1. It would make things much >> easier for me. I'm not sure why he's still using the javax compatible code. >> He's a small operation. Re-writing the code to use gnu namespace sounds like >> a major overhaul. Was it? >> > > I found it quite easy. In fact, in order to accommodate the > transition, I actually separated all of the code that deals directly > with the Comm API or RXTX into a helper class. The helper class was > then coded to use reflection to determine which library was available > and then instantiate the necessary objects. No direct imports of > either library are used. The main application just needs to get it's > hands on the IO streams and need not deal directly with the libraries. > Other programs may not be so simple... > > But this doesn't really help you unless your vendor forks over the > source code... > > Jeff, This may not help me directly, but I'm going to forward this thread to the vendor. I think he'll be open to making things work. Thanks again, Rick Knight From agusmunioz at gmail.com Thu Aug 7 16:39:51 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Thu, 7 Aug 2008 19:39:51 -0300 Subject: [Rxtx] How to send ack? Message-ID: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Hi, I'm still learning about serial communication and I have some doubts. I've got this question about how to do the following thing in rxtx. I have this hardware that connect to a PC using a serial port. These hardware receives data from a telephone line, proccess it, and then send it forward to the serial port. I've used a program named wincomm that shows what information is send it through the serial port and I have the nex behaviour: The hardware has a buffer where all data is stored, that cannot be sent it through the seria port. The program reads the first data send it by the hardware, and keep reading the same data always. There is a button in the application that says enable Ack, and when I click, then the hardware start to send all the stored information, and all the information is shown. I write a class, using rxtx that reads the serial port, and the same thing happens, it remains reading the same (first) data all the time. And I thing something like the enable Ack I'm missing. How can I do this enable Ack from my java code using rxtx? Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080807/e0a0f9a1/attachment-0028.html From ajmas at sympatico.ca Thu Aug 7 18:26:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 7 Aug 2008 20:26:41 -0400 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: <4BF42297-81E2-4BB8-A89F-1D43588379AE@sympatico.ca> On 6-Aug-08, at 19:40 , Bruce Boyes wrote: >> Unless I have missed the documentation for RXTX? I javadocced the >> RXTX >> source but information (to me) is minimal. >> Somewhere I got the impression that the Sun Comm API docs is, or was, >> compatible with RXTX, what is the best docs to use in conjuntion >> with RXTX >> and where may the be available? > > Yeah, this is one of my concerns/beefs. There is little documentation > for RXTX and it isn't just the same as javaxcomm. > > I would be willing to help out writing docs for RXTX! Yes really... > esp if we can fix the Bluetooth issues. If you want to contribute documentation then the best place to do that is the wiki. If there is anything missing or that could be improved on then please do so. If there are any points that you would like to see improved, for which you don't have the knowledge then ask on the mailing list for a volunteer. Andre From florianmanschwetus at gmx.de Fri Aug 8 03:04:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Fri, 08 Aug 2008 11:04:14 +0200 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Message-ID: <489C0C0E.2020401@gmx.de> Agustin Mu?oz schrieb: > Hi, I'm still learning about serial communication and I have some > doubts. I've got this question about how to do the following thing in rxtx. > I have this hardware that connect to a PC using a serial port. These > hardware receives data from a telephone line, proccess it, and then send > it forward to the serial port. I've used a program named wincomm that > shows what information is send it through the serial port and I have the > nex behaviour: > > The hardware has a buffer where all data is stored, that cannot be sent > it through the seria port. > The program reads the first data send it by the hardware, and keep > reading the same data always. > There is a button in the application that says enable Ack, and when I > click, then the hardware start to send all the stored information, and > all the information is shown. > > I write a class, using rxtx that reads the serial port, and the same > thing happens, it remains reading the same (first) data all the time. > And I thing something like the enable Ack I'm missing. > How can I do this enable Ack from my java code using rxtx? Afaik, a look at man ascii reveals: Okt Dez Hex Char 006 6 06 ACK So, i hope this will do the job: send(6); florian > > Thanks in advance > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/5b4965f8/attachment-0028.bin From agusmunioz at gmail.com Fri Aug 8 16:31:00 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 19:31:00 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <489C0C0E.2020401@gmx.de> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> Message-ID: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Hi Florian, thanks for the answer. By send(6) you mean to get the port OutputStream and write a 6? I try that but it didn't work. Any suggestion? Thanks On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < florianmanschwetus at gmx.de> wrote: > Agustin Mu?oz schrieb: > > Hi, I'm still learning about serial communication and I have some doubts. >> I've got this question about how to do the following thing in rxtx. >> I have this hardware that connect to a PC using a serial port. These >> hardware receives data from a telephone line, proccess it, and then send it >> forward to the serial port. I've used a program named wincomm that shows >> what information is send it through the serial port and I have the nex >> behaviour: >> >> The hardware has a buffer where all data is stored, that cannot be sent >> it through the seria port. >> The program reads the first data send it by the hardware, and keep reading >> the same data always. >> There is a button in the application that says enable Ack, and when I >> click, then the hardware start to send all the stored information, and all >> the information is shown. >> >> I write a class, using rxtx that reads the serial port, and the same thing >> happens, it remains reading the same (first) data all the time. And I thing >> something like the enable Ack I'm missing. >> How can I do this enable Ack from my java code using rxtx? >> > Afaik, a look at man ascii reveals: > Okt Dez Hex Char > 006 6 06 ACK > So, i hope this will do the job: > send(6); > > florian > >> >> Thanks in advance >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/7f3fba42/attachment-0027.html From agusmunioz at gmail.com Fri Aug 8 18:39:27 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 21:39:27 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Message-ID: <988288430808081739x7f9e7889id82591d5a9e2b4f6@mail.gmail.com> Ok, Florian, it works!! my problem was that I've been sending, through the OutputStream, the bytes of 6 as a string: out.write("6".getBytes()); but then I realized that you can write an int on an OuptuStream, so I tried that and It works: out.write(6); Thank you for the guidance!! On Fri, Aug 8, 2008 at 7:31 PM, Agustin Mu?oz wrote: > Hi Florian, thanks for the answer. By send(6) you mean to get the port > OutputStream and write a 6? > > I try that but it didn't work. > > Any suggestion? > > Thanks > > > On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < > florianmanschwetus at gmx.de> wrote: > >> Agustin Mu?oz schrieb: >> >> Hi, I'm still learning about serial communication and I have some doubts. >>> I've got this question about how to do the following thing in rxtx. >>> I have this hardware that connect to a PC using a serial port. These >>> hardware receives data from a telephone line, proccess it, and then send it >>> forward to the serial port. I've used a program named wincomm that shows >>> what information is send it through the serial port and I have the nex >>> behaviour: >>> >>> The hardware has a buffer where all data is stored, that cannot be sent >>> it through the seria port. >>> The program reads the first data send it by the hardware, and keep >>> reading the same data always. >>> There is a button in the application that says enable Ack, and when I >>> click, then the hardware start to send all the stored information, and all >>> the information is shown. >>> >>> I write a class, using rxtx that reads the serial port, and the same >>> thing happens, it remains reading the same (first) data all the time. And I >>> thing something like the enable Ack I'm missing. >>> How can I do this enable Ack from my java code using rxtx? >>> >> Afaik, a look at man ascii reveals: >> Okt Dez Hex Char >> 006 6 06 ACK >> So, i hope this will do the job: >> send(6); >> >> florian >> >>> >>> Thanks in advance >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/b918ab3d/attachment-0027.html From florianmanschwetus at gmx.de Sat Aug 9 00:45:43 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Sat, 09 Aug 2008 08:45:43 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4899667C.6010706@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> Message-ID: <489D3D17.9090209@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >> Florian Manschwetus wrote: >>> Ok, sounds fine for the receiving problem. >>> But why i have to wait after each byte when sending a command squence? >>> (the for loop in send command) >> >> Hi Florian, >> I'd imagine you probably don't! You could send all bytes in one go and >> RXTX would send them. The problem is most probably the other end: >> perhaps it has a really small buffer, some non-standard UART, or a >> crazy timing issue. If you attach a terminal to your output and send >> all the bytes of a command in one go they should appear no problem. >> >> Regards, >> Michael Erskine. >> > correct with a terminal on the other end it works, my idea was that this > basic baud has some influence. Could some one explain what it is for? > > Florian To make it more clear, my problem is that i can't use: outputStream.write(byte[]); => Beamer doesn't understand the sequence. (mostly no answer when he answers then *001) when i use this construct instead: for (int i = 0; i < command.length; i++) { this.outputStream.write(command[i]); try { Thread.sleep(25); } catch (InterruptedException e) { // TODO Auto-generated catch block e.printStackTrace(); } } it works nearly reliable. So what could it be? This Basic Baud is what exactly? Florian -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080809/692304ee/attachment-0027.bin From tjarvi at qbang.org Sat Aug 9 16:37:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Aug 2008 16:37:19 -0600 (MDT) Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489D3D17.9090209@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> <489D3D17.9090209@gmx.de> Message-ID: On Sat, 9 Aug 2008, Florian Manschwetus wrote: > Florian Manschwetus schrieb: >> Michael Erskine schrieb: >>> Florian Manschwetus wrote: >>>> Ok, sounds fine for the receiving problem. >>>> But why i have to wait after each byte when sending a command squence? >>>> (the for loop in send command) >>> >>> Hi Florian, >>> I'd imagine you probably don't! You could send all bytes in one go and >>> RXTX would send them. The problem is most probably the other end: perhaps >>> it has a really small buffer, some non-standard UART, or a crazy timing >>> issue. If you attach a terminal to your output and send all the bytes of a >>> command in one go they should appear no problem. >>> >>> Regards, >>> Michael Erskine. >>> >> correct with a terminal on the other end it works, my idea was that this >> basic baud has some influence. Could some one explain what it is for? >> >> Florian > To make it more clear, > my problem is that i can't use: > outputStream.write(byte[]); > => Beamer doesn't understand the sequence. (mostly no answer when he answers > then *001) > > when i use this construct instead: > > for (int i = 0; i < command.length; i++) { > this.outputStream.write(command[i]); > try { > Thread.sleep(25); > } catch (InterruptedException e) { > // TODO Auto-generated catch block > e.printStackTrace(); > } > } > > it works nearly reliable. > > So what could it be? This Basic Baud is what exactly? > I suspect you are using the 'moon protocol' and don't know it. RXTX enables this by default. The buffer on the other end is first in first out while reading. If the buffer is full, the bits are hand carried to the moon and burried. Then if the other side reads a couple bytes, two more bytes go into the buffer followed by more moon protocol. The resulting array of bytes the other side reads may appear to be scrambled until you go to the moon, get the bits and insert them in the right place. Flow control can prevent the default moon protocol and throttles the communiation by almost writing a byte at a time as need be. Hardware flow control is preferable but software flow control should also work. Read and write can appear to hang if the other side is not connected. This is why we don't enable them all the time. If you can't use flow control, you have to take care with the moon protocol and give the other side time to read. That is what your slower version of write is doing. -- Trent Jarvi tjarvi at qbang.org From rxtx at allenjb.me.uk Mon Aug 11 08:06:36 2008 From: rxtx at allenjb.me.uk (AllenJB) Date: Mon, 11 Aug 2008 15:06:36 +0100 Subject: [Rxtx] Disabling EV_RXFLAG Message-ID: <48A0476C.2090800@allenjb.me.uk> Hi all, I'm working with a device which does not use an EvtChar and need to disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an event mask of FD 01 00 00. The reference software I have uses FB 00 00 00. With the rxtx mask I get framing errors which I believe are caused when the EvtChar is received. Is there currently a way with rxtx (I've using rxtx from Java) to disable EV_RXFLAG? If not from Java, where would I start if I wanted to turn the EV_RXFLAG option off in the C code? I've had a grep of the rxtx source code, but I can't see where EV_RXFLAG is being set. Thanks in advance, AllenJB From tjarvi at qbang.org Mon Aug 11 14:17:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Aug 2008 14:17:27 -0600 (MDT) Subject: [Rxtx] Disabling EV_RXFLAG In-Reply-To: <48A0476C.2090800@allenjb.me.uk> References: <48A0476C.2090800@allenjb.me.uk> Message-ID: On Mon, 11 Aug 2008, AllenJB wrote: > Hi all, > > I'm working with a device which does not use an EvtChar and need to > disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an > event mask of FD 01 00 00. The reference software I have uses FB 00 00 > 00. With the rxtx mask I get framing errors which I believe are caused > when the EvtChar is received. > > Is there currently a way with rxtx (I've using rxtx from Java) to > disable EV_RXFLAG? > > If not from Java, where would I start if I wanted to turn the EV_RXFLAG > option off in the C code? I've had a grep of the rxtx source code, but I > can't see where EV_RXFLAG is being set. > > Thanks in advance, > > AllenJB Hi Allen, I'd look at termios.c::tcsetattr() and termios.c::FillDCB() -- Trent Jarvi tjarvi at qbang.org From superdadusa at gmail.com Tue Aug 12 13:57:32 2008 From: superdadusa at gmail.com (John Choi) Date: Tue, 12 Aug 2008 13:57:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. Message-ID: Hi all, Just let you all know I just start to learn Java. I have download the serial comm package and the source code from open source communities.. I was able to verify with the given message string via serial monitor. when the given message string sends to the serial port then the character return added to the end of string by default if I use "Hello World" however if I changed to something else other than "Hello, World" there is no character return add to the end of string. I thing the library download from rxtx.org has implemented for the special strings. I can do like "login\n" in the string message to make character return but I don't want to add this individual custom character for each command return in every static message string I send, Can any who have done this might help me? Basically, something like this,, Write and add function to the program write a command, Reads the respond from a serial device.. Function handles multiple messages, Write: "com open" Read: Welcome to my world" expected Write: "admin" Read: Password?, expected Write: "admin" Read: you are successfully login terminal, expected. And I need to add a separate function handler handles a character return add to the each command above. If anyone can help this I can do the reset? Thank you in advance, John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0023.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SerialIO.java Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0023.pl From Steffen.DETTMER at ingenico.com Wed Aug 13 02:16:38 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 13 Aug 2008 10:16:38 +0200 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: References: Message-ID: <20080813081638.GA25412@elberon.bln.de.ingenico.com> * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > I can do like "login\n" in the string message to make character > return but I don't want to add this individual custom character > for each command return in every static message string I send, and why not?! > Can any who have done this might help me? what's about with writing a small wrapper function adding the carriage return? However, this would be slow, because either you call write two times (very bad) or the string needs to be copied, \n appended and written (since you are using Java Performance probably isn't so critical). Personally I would write `"login\n"' and `username + "\n"' etc., because since it is part of the command it should be part of the command definition string. > Basically, something like this,, Write and add function to the program write > a command, Reads the respond from a serial device.. correctly reading a `line' is more difficult. If you cannot make assumptions about timeouts and/or you need to have low delay, you need to read byte wise. If you need to save CPU resources you might need to add some buffering layer that you can read byte-wise but that is reading blockwise with some small timeout (lets say for serial lines something around byte transmission time times three or so). > /* > * To change this template, choose Tools | Templates > * and open the template in the editor. > */ :) > package joliba; > > /** > * > * @author root > */ :) > // derived from SUN's examples in the javax.comm package > import java.io.*; > import java.util.*; > //import javax.comm.*; // for SUN's serial/parallel port libraries > import gnu.io.*; // for rxtxSerial library > > public class SerialIO implements Runnable, SerialPortEventListener { > static CommPortIdentifier portId; > static CommPortIdentifier saveportId; > static Enumeration portList; > InputStream inputStream; > SerialPort serialPort; > Thread readThread; You need a thread for your synchronous RPC-style protocol? > static String messageString = "Hello, world!"; > static OutputStream outputStream; > static boolean outputBufferEmptyFlag = false; > > public static void main(String[] args) { > boolean portFound = false; > String defaultPort; > > // determine the name of the serial port on several operating systems > String osname = System.getProperty("os.name","").toLowerCase(); > if ( osname.startsWith("windows") ) { > // windows > defaultPort = "COM1"; > } else if (osname.startsWith("linux")) { > // linux > defaultPort = "/dev/ttyS0"; > } else if ( osname.startsWith("mac") ) { > // mac > defaultPort = "????"; > } else { > System.out.println("Sorry, your operating system is not supported"); > return; > } Is such a construction recommended? Isn't there some abstraction (like COM1 working on any platform)? [...] > try { > // activate the OUTPUT_BUFFER_EMPTY notifier > serialPort.notifyOnOutputEmpty(true); > } catch (Exception e) { > System.out.println("Error setting event notification"); > System.out.println(e.toString()); > System.exit(-1); > } I doubt that -1 is defined, probably some 127 or so would be the result, maybe better simply `throw e'? > public void writetoport() { > System.out.println("Writing \""+messageString+"\" to "+serialPort.getName()); > try { > // write string to serial port > outputStream.write(messageString.getBytes()); > } catch (IOException e) {} > } maybe something like /** * Writes the given output string and an additional carriage * return to the current outputStream. */ public void writeStringToPort( /** The output string (without CR). */ String output ) throws IOException { String outputLine = output + "\n"; outputStream.write(outputLine.getBytes()); } ? > > public SerialIO() { > // initalize serial port > try { > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > } catch (PortInUseException e) {} if the port is in use, you continue? Wonder that this works in Java, I would assume serialPort beeing uninitialized which AFAIK is an error in Java. > try { > inputStream = serialPort.getInputStream(); > } catch (IOException e) {} > > try { > serialPort.addEventListener(this); > } catch (TooManyListenersException e) {} > > // activate the DATA_AVAILABLE notifier > serialPort.notifyOnDataAvailable(true); > > try { > // set port parameters > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > } catch (UnsupportedCommOperationException e) {} > > // start the read thread > readThread = new Thread(this); > readThread.start(); > > } I think in all those exception cases you can abort, because it is unlikely that ignoring those errors allow a successful continuation, so in this case maybe it would be better to add a throw clause to the method. > public void run() { > // first thing in the thread, we initialize the write operation > initwritetoport(); > try { > while (true) { > // write string to port, the serialEvent will read it > writetoport(); > Thread.sleep(1000); > } > } catch (InterruptedException e) {} > } Does this make sense? Your `SimpleReadApp' writes one and the same string each second? > public void serialEvent(SerialPortEvent event) { > switch (event.getEventType()) { > case SerialPortEvent.BI: > case SerialPortEvent.OE: > case SerialPortEvent.FE: > case SerialPortEvent.PE: > case SerialPortEvent.CD: > case SerialPortEvent.CTS: > case SerialPortEvent.DSR: > case SerialPortEvent.RI: > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > break; > case SerialPortEvent.DATA_AVAILABLE: > // we get here if data has been received > byte[] readBuffer = new byte[20]; > try { > // read data > while (inputStream.available() > 0) { > int numBytes = inputStream.read(readBuffer); > } > // print data > String result = new String(readBuffer); > System.out.println("Read: "+result); > } catch (IOException e) {} I doubt that this is correct. I would assume you will get a 20 bytes result always, if more bytes would be available they would be printed in a second line but if less bytes are read I'd assume that the buffer/result contains zero bytes from implicite readBuffer contents initialisation (zero is no string terminator in Java AFAIK). > break; > } > } > } oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From florianmanschwetus at gmx.de Wed Aug 13 06:09:31 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 13 Aug 2008 14:09:31 +0200 Subject: [Rxtx] someone has seen such errors? Message-ID: <48A2CEFB.90007@gmx.de> I mean my communication mostly works, but it is far from perfect could this be the reason? Florian Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/949b9947/attachment-0023.bin From superdadusa at gmail.com Wed Aug 13 08:40:32 2008 From: superdadusa at gmail.com (John Choi) Date: Wed, 13 Aug 2008 08:40:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: <20080813081638.GA25412@elberon.bln.de.ingenico.com> References: <20080813081638.GA25412@elberon.bln.de.ingenico.com> Message-ID: Thank you so much Steffen and I will try that suggestion. John On 8/13/08, Steffen DETTMER wrote: > > * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > > I can do like "login\n" in the string message to make character > > return but I don't want to add this individual custom character > > for each command return in every static message string I send, > > and why not?! > > > Can any who have done this might help me? > > what's about with writing a small wrapper function adding the > carriage return? > However, this would be slow, because either you call write two > times (very bad) or the string needs to be copied, \n appended > and written (since you are using Java Performance probably isn't > so critical). > > Personally I would write `"login\n"' and `username + "\n"' etc., > because since it is part of the command it should be part of the > command definition string. > > > Basically, something like this,, Write and add function to the program > write > > a command, Reads the respond from a serial device.. > > correctly reading a `line' is more difficult. If you cannot make > assumptions about timeouts and/or you need to have low delay, you > need to read byte wise. If you need to save CPU resources you > might need to add some buffering layer that you can read > byte-wise but that is reading blockwise with some small timeout > (lets say for serial lines something around byte transmission > time times three or so). > > > /* > > * To change this template, choose Tools | Templates > > * and open the template in the editor. > > */ > > :) > > > package joliba; > > > > /** > > * > > * @author root > > */ > > :) > > > // derived from SUN's examples in the javax.comm package > > import java.io.*; > > import java.util.*; > > //import javax.comm.*; // for SUN's serial/parallel port libraries > > import gnu.io.*; // for rxtxSerial library > > > > public class SerialIO implements Runnable, SerialPortEventListener { > > static CommPortIdentifier portId; > > static CommPortIdentifier saveportId; > > static Enumeration portList; > > InputStream inputStream; > > SerialPort serialPort; > > Thread readThread; > > You need a thread for your synchronous RPC-style protocol? > > > static String messageString = "Hello, world!"; > > static OutputStream outputStream; > > static boolean outputBufferEmptyFlag = false; > > > > public static void main(String[] args) { > > boolean portFound = false; > > String defaultPort; > > > > // determine the name of the serial port on several operating > systems > > String osname = System.getProperty("os.name","").toLowerCase(); > > if ( osname.startsWith("windows") ) { > > // windows > > defaultPort = "COM1"; > > } else if (osname.startsWith("linux")) { > > // linux > > defaultPort = "/dev/ttyS0"; > > } else if ( osname.startsWith("mac") ) { > > // mac > > defaultPort = "????"; > > } else { > > System.out.println("Sorry, your operating system is not > supported"); > > return; > > } > > Is such a construction recommended? Isn't there some abstraction > (like COM1 working on any platform)? > > [...] > > try { > > // activate the OUTPUT_BUFFER_EMPTY notifier > > serialPort.notifyOnOutputEmpty(true); > > } catch (Exception e) { > > System.out.println("Error setting event notification"); > > System.out.println(e.toString()); > > System.exit(-1); > > } > > I doubt that -1 is defined, probably some 127 or so would be the > result, maybe better simply `throw e'? > > > public void writetoport() { > > System.out.println("Writing \""+messageString+"\" to > "+serialPort.getName()); > > try { > > // write string to serial port > > outputStream.write(messageString.getBytes()); > > } catch (IOException e) {} > > } > > maybe something like > > /** > * Writes the given output string and an additional carriage > * return to the current outputStream. > */ > public void > writeStringToPort( > /** The output string (without CR). */ > String output > ) throws IOException > { > String outputLine = output + "\n"; > outputStream.write(outputLine.getBytes()); > } > > ? > > > > > public SerialIO() { > > // initalize serial port > > try { > > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > > } catch (PortInUseException e) {} > > if the port is in use, you continue? Wonder that this works in > Java, I would assume serialPort beeing uninitialized which AFAIK > is an error in Java. > > > try { > > inputStream = serialPort.getInputStream(); > > } catch (IOException e) {} > > > > try { > > serialPort.addEventListener(this); > > } catch (TooManyListenersException e) {} > > > > // activate the DATA_AVAILABLE notifier > > serialPort.notifyOnDataAvailable(true); > > > > try { > > // set port parameters > > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > } catch (UnsupportedCommOperationException e) {} > > > > // start the read thread > > readThread = new Thread(this); > > readThread.start(); > > > > } > > I think in all those exception cases you can abort, because it is > unlikely that ignoring those errors allow a successful > continuation, so in this case maybe it would be better to add a > throw clause to the method. > > > public void run() { > > // first thing in the thread, we initialize the write operation > > initwritetoport(); > > try { > > while (true) { > > // write string to port, the serialEvent will read it > > writetoport(); > > Thread.sleep(1000); > > } > > } catch (InterruptedException e) {} > > } > > Does this make sense? Your `SimpleReadApp' writes one and the > same string each second? > > > public void serialEvent(SerialPortEvent event) { > > switch (event.getEventType()) { > > case SerialPortEvent.BI: > > case SerialPortEvent.OE: > > case SerialPortEvent.FE: > > case SerialPortEvent.PE: > > case SerialPortEvent.CD: > > case SerialPortEvent.CTS: > > case SerialPortEvent.DSR: > > case SerialPortEvent.RI: > > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > > break; > > case SerialPortEvent.DATA_AVAILABLE: > > // we get here if data has been received > > byte[] readBuffer = new byte[20]; > > try { > > // read data > > while (inputStream.available() > 0) { > > int numBytes = inputStream.read(readBuffer); > > } > > // print data > > String result = new String(readBuffer); > > System.out.println("Read: "+result); > > } catch (IOException e) {} > > I doubt that this is correct. I would assume you will get a 20 > bytes result always, if more bytes would be available they would > be printed in a second line but if less bytes are read I'd assume > that the buffer/result contains zero bytes from implicite > readBuffer contents initialisation (zero is no string terminator > in Java AFAIK). > > > break; > > } > > } > > } > > oki, > > Steffen > > About Ingenico Throughout the world businesses rely on Ingenico for secure > and expedient electronic transaction acceptance. Ingenico products leverage > proven technology, established standards and unparalleled ergonomics to > provide optimal reliability, versatility and usability. This comprehensive > range of products is complemented by a global array of services and > partnerships, enabling businesses in a number of vertical sectors to accept > transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged > information. If you are not the addressee or authorized to receive this for > the addressee, you must not use, copy, disclose or take any action based on > this message or any information herein. If you have received this message in > error, please advise the sender immediately by reply e-mail and delete this > message. Thank you for your cooperation. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/73c4135c/attachment-0022.html From ajmas at sympatico.ca Sat Aug 16 07:15:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 09:15:41 -0400 Subject: [Rxtx] someone has seen such errors? In-Reply-To: <48A2CEFB.90007@gmx.de> References: <48A2CEFB.90007@gmx.de> Message-ID: <43B5E8DA-1D93-4D90-809B-AAF35FF724C5@sympatico.ca> On 13-Aug-08, at 08:09 , Florian Manschwetus wrote: > I mean my communication mostly works, but it is far from perfect > could this be the reason? > > Florian > > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control Judging by the error messages this looks related to the driver you are using. Do a search for the following string with you favourite search engine, it should turn up a few hits: ftdi_set_termios FAILED to set databits/stopbits/parity Andre From ajmas at sympatico.ca Sat Aug 16 19:12:04 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 21:12:04 -0400 Subject: [Rxtx] Using SerialPortEvent? Message-ID: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Hi, Could someone tell me how I should be using the SerialPortEvent? Am I meant to be waiting for data and then simply reading from the inputstream? If this is the case why no just block on an inputstream read? Andr? From tjarvi at qbang.org Sat Aug 16 19:41:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 16 Aug 2008 19:41:13 -0600 (MDT) Subject: [Rxtx] Using SerialPortEvent? In-Reply-To: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> References: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Message-ID: On Sat, 16 Aug 2008, Andre-John Mas wrote: > Hi, > > Could someone tell me how I should be using the SerialPortEvent? Am I > meant to be waiting for data and then simply reading from the > inputstream? If this is the case why no just block on an inputstream > read? > Polling for data is fine also. It really depends upon what you are trying to do. For instance, if you require x bytes before reading, you can start polling after data is available. If you read on the same thread as your GUI and are waiting for data in a read, the results may be less than desirable. Java programming is 'usually' event driven rather than polling based. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sat Aug 16 20:10:39 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 22:10:39 -0400 Subject: [Rxtx] Using SerialPortEvent? In-Reply-To: References: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Message-ID: <3E495D4C-BB28-4845-A6AB-984C9A826BDF@sympatico.ca> On 16-Aug-08, at 21:41 , Trent Jarvi wrote: > On Sat, 16 Aug 2008, Andre-John Mas wrote: > >> Hi, >> >> Could someone tell me how I should be using the SerialPortEvent? Am I >> meant to be waiting for data and then simply reading from the >> inputstream? If this is the case why no just block on an inputstream >> read? >> > > Polling for data is fine also. It really depends upon what you are > trying to do. For instance, if you require x bytes before reading, > you can start polling after data is available. If you read on the > same thread as your GUI and are waiting for data in a read, the > results may be less than desirable. > > Java programming is 'usually' event driven rather than polling based. Sounds good. I thought I would use this opportunity to provide a event based version of the TwoWaySerialComm example. Could you just validate it before I add it to the Wiki: package ajmas74.experimental; import gnu.io.CommPort; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; import gnu.io.SerialPortEvent; import gnu.io.SerialPortEventListener; import java.io.IOException; import java.io.InputStream; import java.io.OutputStream; /** * This version of the TwoWaySerialComm example makes use of the * SerialPortEventListener to avoid polling. * * @author ajmas * */ public class TwoWaySerialComm { public TwoWaySerialComm() { super(); } void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { CommPort commPort = portIdentifier.open(this.getClass().getName(),2000); if ( commPort instanceof SerialPort ) { SerialPort serialPort = (SerialPort) commPort; serialPort .setSerialPortParams (57600 ,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); (new Thread(new SerialWriter(out))).start(); serialPort.addEventListener(new SerialReader(in)); } else { System.out.println("Error: Only serial ports are handled by this example."); } } } /** * Handles the input coming from the serial port. A new line character * is treated as the end of a block in this example. */ public static class SerialReader implements SerialPortEventListener { private InputStream in; private byte[] buffer = new byte[1024]; public SerialReader ( InputStream in ) { this.in = in; } public void serialEvent(SerialPortEvent arg0) { int data; try { int len = 0; while ( ( data = in.read()) > -1 ) { if ( data != '\n' ) { break; } buffer[len++] = (byte) data; } System.out.print(new String(buffer,0,len)); } catch ( IOException e ) { e.printStackTrace(); System.exit(-1); } } } /** */ public static class SerialWriter implements Runnable { OutputStream out; public SerialWriter ( OutputStream out ) { this.out = out; } public void run () { try { int c = 0; while ( ( c = System.in.read()) > -1 ) { this.out.write(c); } } catch ( IOException e ) { e.printStackTrace(); System.exit(-1); } } } public static void main ( String[] args ) { try { (new TwoWaySerialComm()).connect("COM3"); } catch ( Exception e ) { e.printStackTrace(); } } } From lfarkas at lfarkas.org Tue Aug 19 07:32:59 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Tue, 19 Aug 2008 15:32:59 +0200 Subject: [Rxtx] JNI or CNI Message-ID: <48AACB8B.9060606@lfarkas.org> hi, what is the current recommended way to rxtx on linux JNI or it's better to use CNI? is the CNI version fully functional and the same level as the JNI? i currently try to make a rhel/centos/fedora rpm for rxtx but has many problems with the standard dir structure. yours. -- Levente "Si vis pacem para bellum!" From lfarkas at lfarkas.org Tue Aug 19 08:47:34 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Tue, 19 Aug 2008 16:47:34 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel Message-ID: <48AADD06.7040809@lfarkas.org> hi, newer or not so newer linux kernel do not contain the UTS_RELEASE so the current rxtx is not compile on the latest kernels. even if it's commented out in the cvs configure there are other places. i attcahed a patch which fix it (or at least doesn't cause error at non-debug build). ps. is there any plan to the new 2.1-8 release in the near future? there are many changes (at least the license change in all file and in this case create a diff is very difficult)? the latest release more then 2 years old:-( -- Levente "Si vis pacem para bellum!" -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-2.1-uts.patch Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080819/ab5d38ac/attachment-0016.pl From ajmas at sympatico.ca Tue Aug 19 16:21:53 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 19 Aug 2008 18:21:53 -0400 Subject: [Rxtx] Event based example Message-ID: <24735BFB-B088-4B84-8173-FE98DF63B12F@sympatico.ca> Hi, I have just posted an example of using SerialPortEventListener in the Wiki: http://rxtx.qbang.org/wiki/index.php/Event_Based_Two_Way_Communication If you see any issues please could you let me know, or makes the changes. Andre From Martin.Oberhuber at windriver.com Fri Aug 22 04:02:24 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 22 Aug 2008 12:02:24 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <48AADD06.7040809@lfarkas.org> References: <48AADD06.7040809@lfarkas.org> Message-ID: <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> Farkas, there are indeed efforts to get a new RXTX release out the door. Your experience as a package maintainer would likely be helpful during these efforts, since I'd think it makes sense to keep the patches minimal that you must make to have the source compile in your environment. What are the things that you find problematic, apart from the UTS thing that you have mentioned before? What is the timing that you have in mind for your package? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Farkas Levente > Sent: Tuesday, August 19, 2008 4:48 PM > To: rxtx at qbang.org > Subject: [Rxtx] UTS_RELEASE not defined in newer kernel > > hi, > newer or not so newer linux kernel do not contain the > UTS_RELEASE so the > current rxtx is not compile on the latest kernels. even if it's > commented out in the cvs configure there are other places. > i attcahed a patch which fix it (or at least doesn't cause error at > non-debug build). > > ps. is there any plan to the new 2.1-8 release in the near > future? there > are many changes (at least the license change in all file and in this > case create a diff is very difficult)? the latest release more then 2 > years old:-( > > -- > Levente "Si vis pacem para bellum!" > From lfarkas at lfarkas.org Fri Aug 22 04:36:26 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Fri, 22 Aug 2008 12:36:26 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> References: <48AADD06.7040809@lfarkas.org> <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> Message-ID: <48AE96AA.6090505@lfarkas.org> hi, the packages already build for fedora-9 and centos-5 and here: http://www.lfarkas.org/linux/packages/ what i've to patch, the UTS, the configure script, but it's already fixed in the cvs (in another way) and the loadlibrary. the reasons for last one can be found here: https://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_files_that_use_JNI after we test it i'd like to add these packages to fedora and epel main repository (that's why it's be useful a new release after 2 years:-) imho versions are cheap and why not just release 2.1-8? the real code changes are minimal and if something critical bug found still can release 2.1-9:-) ps. and would be better to use simple number for version like 2.1-7 rather then 2.1-7v2. Oberhuber, Martin wrote: > Farkas, > > there are indeed efforts to get a new RXTX release out the > door. Your experience as a package maintainer would likely > be helpful during these efforts, since I'd think it makes > sense to keep the patches minimal that you must make to > have the source compile in your environment. > > What are the things that you find problematic, apart from > the UTS thing that you have mentioned before? > > What is the timing that you have in mind for your package? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >> On Behalf Of Farkas Levente >> Sent: Tuesday, August 19, 2008 4:48 PM >> To: rxtx at qbang.org >> Subject: [Rxtx] UTS_RELEASE not defined in newer kernel >> >> hi, >> newer or not so newer linux kernel do not contain the >> UTS_RELEASE so the >> current rxtx is not compile on the latest kernels. even if it's >> commented out in the cvs configure there are other places. >> i attcahed a patch which fix it (or at least doesn't cause error at >> non-debug build). >> >> ps. is there any plan to the new 2.1-8 release in the near >> future? there >> are many changes (at least the license change in all file and in this >> case create a diff is very difficult)? the latest release more then 2 >> years old:-( >> >> -- >> Levente "Si vis pacem para bellum!" >> -- Levente "Si vis pacem para bellum!" From tjarvi at qbang.org Fri Aug 22 18:50:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Aug 2008 18:50:32 -0600 (MDT) Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <48AE96AA.6090505@lfarkas.org> References: <48AADD06.7040809@lfarkas.org> <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> <48AE96AA.6090505@lfarkas.org> Message-ID: Hi Farkas, The v2 was simply the second build - no code changes. We are comming out with a new release shortly. I would encourage working with distros as you are. The building of rxtx turns out to be a bottle neck in quick releases. We do want stable releases that work for a year or more but I would have no problems with quicker cycles on developing work. I would have no problem working with someone that did builds that receive less testing more often but they do have to come out for multiple platforms from this end. Thanks for the links. On Fri, 22 Aug 2008, Farkas Levente wrote: > hi, > the packages already build for fedora-9 and centos-5 and here: > http://www.lfarkas.org/linux/packages/ > what i've to patch, the UTS, the configure script, but it's already > fixed in the cvs (in another way) and the loadlibrary. the reasons for > last one can be found here: > https://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_files_that_use_JNI > after we test it i'd like to add these packages to fedora and epel main > repository (that's why it's be useful a new release after 2 years:-) > imho versions are cheap and why not just release 2.1-8? the real code > changes are minimal and if something critical bug found still can > release 2.1-9:-) > > ps. and would be better to use simple number for version like 2.1-7 > rather then 2.1-7v2. > > Oberhuber, Martin wrote: >> Farkas, >> >> there are indeed efforts to get a new RXTX release out the >> door. Your experience as a package maintainer would likely >> be helpful during these efforts, since I'd think it makes >> sense to keep the patches minimal that you must make to >> have the source compile in your environment. >> >> What are the things that you find problematic, apart from >> the UTS thing that you have mentioned before? >> >> What is the timing that you have in mind for your package? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >>> On Behalf Of Farkas Levente >>> Sent: Tuesday, August 19, 2008 4:48 PM >>> To: rxtx at qbang.org >>> Subject: [Rxtx] UTS_RELEASE not defined in newer kernel >>> >>> hi, >>> newer or not so newer linux kernel do not contain the >>> UTS_RELEASE so the >>> current rxtx is not compile on the latest kernels. even if it's >>> commented out in the cvs configure there are other places. >>> i attcahed a patch which fix it (or at least doesn't cause error at >>> non-debug build). >>> >>> ps. is there any plan to the new 2.1-8 release in the near >>> future? there >>> are many changes (at least the license change in all file and in this >>> case create a diff is very difficult)? the latest release more then 2 >>> years old:-( >>> >>> -- >>> Levente "Si vis pacem para bellum!" >>> > > > From andy at triera.net Sat Aug 23 15:17:44 2008 From: andy at triera.net (Andy Rozman) Date: Sat, 23 Aug 2008 21:17:44 +0000 Subject: [Rxtx] port not identified on FreeBSD In-Reply-To: References: Message-ID: <48B07E78.2030306@triera.net> Hi ! I have one small problem... I have started using FreeBSD in last few days and I have come accross a problem with rxtx on FreeBSD. I am using usb-to-serial converter, which is identified under FreeBSD without problem as ucom0, and creates link under /dev called ttyU0, which is correct way to be done under FreeBSD (if device would be unidentified it would be called ugen0 - as usb generic). Problem is that I say to rxtx to get my all serial ports this one is not among them. Which names are permissable under linux-like implementations? Which will be accepted as serial ports? Andy From tjarvi at qbang.org Sat Aug 23 13:57:45 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 23 Aug 2008 13:57:45 -0600 (MDT) Subject: [Rxtx] port not identified on FreeBSD In-Reply-To: <48B07E78.2030306@triera.net> References: <48B07E78.2030306@triera.net> Message-ID: On Sat, 23 Aug 2008, Andy Rozman wrote: > Hi ! > > I have one small problem... I have started using FreeBSD in last few > days and I have come accross a problem with rxtx on FreeBSD. > > I am using usb-to-serial converter, which is identified under FreeBSD > without problem as ucom0, and creates link under /dev called > ttyU0, which is correct way to be done under FreeBSD (if device would be > unidentified it would be called ugen0 - as usb generic). Problem is that > I say to rxtx to get my all serial ports this one is not among them. > Which names are permissable under linux-like implementations? Which will > be accepted as serial ports? > > Andy > Thanks Andy! We will add ttyU* to FreeBSD. For now you can use properties to enable the port. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting#How_does_rxtx_detect_ports.3F__Can_I_override_it.3F The fix: diff -u -r1.16.2.59 RXTXCommDriver.java --- RXTXCommDriver.java 18 Nov 2007 22:32:41 -0000 1.16.2.59 +++ RXTXCommDriver.java 23 Aug 2008 19:55:25 -0000 @@ -644,6 +644,7 @@ { String[] Temp = { "ttyd", //general purpose serial ports + "ttyU", //general purpose USB serial ports "cuaa", //dialout serial ports "ttyA", //Specialix SI/XIO dialin ports "cuaA", //Specialix SI/XIO dialout ports -- Trent Jarvi tjarvi at qbang.org From rick_knight at rlknight.com Mon Aug 4 13:25:10 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Mon, 04 Aug 2008 12:25:10 -0700 Subject: [Rxtx] Sun's Comm API? Message-ID: <48975796.4010600@rlknight.com> I have an application that requires the javax compatible version of RXTX and Sun's comm api. I've been able to download and extract the version of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api anywhere. Can someone tell me where I can find it? Or maybe send me a copy? Also, when I try to build RXTX, configure and make complete successfully but make install failes with this error libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 I've never come accross this error before. How can I get past it? Thanks, Rick From bboyes at systronix.com Mon Aug 4 19:10:01 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:10:01 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48975796.4010600@rlknight.com> References: <48975796.4010600@rlknight.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/cb9c6167/attachment-0032.html From bboyes at systronix.com Mon Aug 4 19:12:37 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:12:37 -0600 Subject: [Rxtx] Towards an RXTX release - CSR BT/USB chipset In-Reply-To: <488FB7E7.8000802@gmail.com> References: <460801A4097E3D4CA04CC64EE648584806C56CF0@ism-mail03.corp.ad.wrs.com> <13557-75390@sneakemail.com> <20980-23424@sneakemail.com> <488FB7E7.8000802@gmail.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/52236088/attachment-0032.html From tjarvi at qbang.org Mon Aug 4 19:42:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 19:42:21 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: On Mon, 4 Aug 2008, Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: > I have an application that requires the javax compatible > version of RXTX > and Sun's comm api. I've been able to download and extract > the version > of RXTX that I need (2.0-7pre2) but I can't find Sun's camm > api > anywhere. Can someone tell me where I can find it? Or maybe > send me a > > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm port > support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have just > a ZIP with only the .class JAR file - no source or docs), has a readme > with these comments: > > This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release.? The 2.0.3 release itself is > no longer distributed.? comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project.? The RxTx project (http://www.rxtx.org ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org) was opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support.? Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins.? Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > ? > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > I hope that is helpful! > It would be nice to work with Sun to resolve those longstanding issues. But it may not be practical unless the process goes as fast and painless as the grandfathering of commapi did. Another option may be the old kaffe extensions that moved to gnu classpathx. These don't have the native libraries but should provide the 2.0 interface and the javax.comm.properties mechansim for SPI. http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Mon Aug 4 20:23:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Mon, 04 Aug 2008 20:23:57 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4897B9BD.5070809@ergotech.com> Has there been any work/would it be possible, to layer a javacomm look-alike on top of the GNU code? The goal is not to move the javax code forward, but to emulate the "legacy" javax packages for people who still need this. Jim Trent Jarvi wrote: > On Mon, 4 Aug 2008, Bruce Boyes wrote: > >> At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible >> version of RXTX >> and Sun's comm api. I've been able to download and extract >> the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm >> api >> anywhere. Can someone tell me where I can find it? Or maybe >> send me a >> >> >> javaxcomm has had a sort of on-again off-again history. The windoze >> version has been languishing for years (literally) but there are newer >> versions for other OS's. >> >> We try to keep links on one of our help pages current: >> http://www.practicalembeddedjava.com/tools/javatools_list.html >> which gets you to here: >> http://java.sun.com/products/javacomm/ >> where it says in fact they no longer even support Windows and Mac: >> "Implementations of the API are currently available for Solaris SPARC, >> Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so >> someone could support it. But I guess that's part of the reason RXTX >> exists! >> >> So one of Sun's own products, SunSPOT, has to use RXTX to get comm port >> support. >> >> The version we use is 2.0 from 11/15/1998. I have posted it on our >> website, which is within the terms of the license agreement contained >> therein (as I understand it). >> >> The last version of javaxcomm for Windows, 2.0.3, (for which I have just >> a ZIP with only the .class JAR file - no source or docs), has a readme >> with these comments: >> >> This distribution contains the comm.jar file original part >> of the COMMAPI 2.0.3 release. The 2.0.3 release itself is >> no longer distributed. comm.jar, which contains the comm >> API java class files (eg. Sun's binary implementation of the >> interface classes), is being made available, unsupported, >> with no obligation to fix bugs, at the request of the RXTX >> project. The RxTx project (http://www.rxtx.org ), uses the >> comm.jar class files, but provides their own native library >> components to provide support for other platforms. >> >> The 2.0.3 comm.jar is being provided in this way because >> as of COMMAPI 3.x, the java binary implementation forked and >> became incompatible with the RxTx project's native code. >> Due to the lack of a clear business case, and to resource >> constraints, no additional resources are being >> provided to provide an alternative engineering solution >> at the time of writing. >> >> RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: >> >> Ultimately the COMMAPI would be better served if a Java >> Community Process JSR (http://www.jcp.org) was opened and >> the COMMAPI was rearchitected to provide a more pluggable >> framework to improve cross-platform support. Such an >> architecture would embody a better defined and better >> documented SPI interface, including a way for comm. ports >> to be revealed to the client application through the API >> via platform-aware plugins. Similarly, native code used >> to access comm port in general could be handled more >> flexibly using a plugin model, whereby on any platform, >> multiple native modules could be in use simultaneously. >> >> Since there are now various ways serial ports can be implemented >> and accessed, modular comm. port JNI native libraries would be >> of benefit insofar as removing the burden of over-generalization >> from any single native component, or inversely, by relieving the >> implicit constraint that comm. drivers be accessed only via a >> monolithic mechanism, such as the UNIX vnode interface. >> >> paul.klissner at sun.com >> 6/10/06 >> >> I hope that is helpful! >> > > It would be nice to work with Sun to resolve those longstanding issues. > But it may not be practical unless the process goes as fast and painless > as the grandfathering of commapi did. > > Another option may be the old kaffe extensions that moved to gnu > classpathx. These don't have the native libraries but should provide > the 2.0 interface and the javax.comm.properties mechansim for SPI. > > http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Mon Aug 4 21:09:15 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 21:09:15 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? Message-ID: Hi Jim, I will not step into the javax.comm namespace without Sun's explicite permission. I fully understand the pain point you are trying to address. In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm Linux) - which remains an integral part of rxtx. At the time it was a win for Sun and rxtx. The Sun commapi license is/was fairly clear that rxtx should not step into that namespace. It made sense as Sun was active in that space and rxtx may go into another namespace - it was an experiment in working with Sun. This may sound silly looking at something that happened almost 10 years ago. In a community of respect which Sun helped create, there is no question about what to do. I hope eventually Sun will step up and do a right thing too. I agree that this is hurting the API more than helping it. There are also questions about how to replace the API in the long term which includes HID support which isn't going well so far. Others that can't even look at Sun's javax.comm today and can look at Kaffe's contribution to classpathx can easily work around such restrictions. On Mon, 4 Aug 2008, Jim Redman wrote: > Has there been any work/would it be possible, to layer a javacomm > look-alike on top of the GNU code? > > The goal is not to move the javax code forward, but to emulate the > "legacy" javax packages for people who still need this. > > Jim > > Trent Jarvi wrote: >> >> It would be nice to work with Sun to resolve those longstanding issues. >> But it may not be practical unless the process goes as fast and painless >> as the grandfathering of commapi did. >> >> Another option may be the old kaffe extensions that moved to gnu >> classpathx. These don't have the native libraries but should provide >> the 2.0 interface and the javax.comm.properties mechansim for SPI. >> >> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From florianmanschwetus at gmx.de Tue Aug 5 05:04:46 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 13:04:46 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: References: <48971C1F.9020806@gmx.de> Message-ID: <489833CE.1040801@gmx.de> Just look at sendCommand in this method I have to place a Thread.sleep(20) after each byte send to get working. Even the event based receive doesn't work fine but this could be may stupidness. The specifikation document (it is on the last pages of the manual) for the beamer could be found on: http://www.optoma.co.uk/support.aspx Florian Manschwetus Trent Jarvi schrieb: > > Hi Florian > > Sorry for the top post in advance. I worry you may not see my answer > under all your code :) > > I have not received this email before. This is 500k of code which I > don't have time to read. I can spend about 5 min on each hobby email > and still get to work in the morning. I have a couple suggestions for > how to get an answer. > > First, cut out your comments and extra code so you can demonstrate the > question (I might even glance and see what is wrong then). Don't go for > a working final product. Isolate the problem using a simple program and > then ask with that as an example. If I did what you just did, I'd have > to post 3/4 of a million lines of code :) > > Second, join the rxtx mail-list and ask there. This will give you 100x > more eyes. I'll also read and try to follow. > > -- > taj > > > > On Mon, 4 Aug 2008, Florian Manschwetus wrote: > >> It could be that my university account is blocked by filters so >> resending from here. >> >> >> Topic is to control Optoma HD80 beamer using rs232 serial chat. >> This code is able to detect power state and switch the beamer on / off. >> connected is the beamer using a digitus usb 2.0 serial adapter with an >> FT232 USB-Serial adapter the systems architecture is amd64. >> >> Please take a look in the sendCommand routine i have to place theire >> those Thread.sleep to get it working. >> Now the question is this correct or is there a better way to get this >> working correctly? >> >> In the javadoc coming with the install i found this: >> setBaudBase >> >> public boolean setBaudBase(int BaudBase) >> throws UnsupportedCommOperationException, >> java.io.IOException >> >> Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 >> before using. >> >> could this explain the error? >> I attached my java source and the protocol description for the beamer >> (available on vendor website). >> >> thx, >> Florian Manschwetus >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: TestRS232.java Type: text/x-java Size: 9143 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0064.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0065.bin From michael.erskine at ketech.com Tue Aug 5 05:53:49 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Tue, 5 Aug 2008 12:53:49 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489833CE.1040801@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> > Just look at sendCommand in this method I have to place a > Thread.sleep(20) after each byte send to get working. Even the event > based receive doesn't work fine but this could be may stupidness. Hi Florian, Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. Regards, Michael Erskine. From florianmanschwetus at gmx.de Tue Aug 5 07:28:15 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:28:15 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> Message-ID: <4898556F.8000208@gmx.de> Michael Erskine schrieb: >> Just look at sendCommand in this method I have to place a >> Thread.sleep(20) after each byte send to get working. Even the event >> based receive doesn't work fine but this could be may stupidness. > > Hi Florian, > > Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. > > Regards, > Michael Erskine. > Ok, sounds fine for the receiving problem. But why i have to wait after each byte when sending a command squence? (the for loop in send command) Florian > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/284f350c/attachment-0031.bin From florianmanschwetus at gmx.de Tue Aug 5 07:44:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:44:14 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <4898592E.2020908@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >>> Just look at sendCommand in this method I have to place a >>> Thread.sleep(20) after each byte send to get working. Even the event >>> based receive doesn't work fine but this could be may stupidness. >> >> Hi Florian, >> >> Yes, naturally you'll have to wait for a response from the other end. >> Why not wait for notification from the event thread perhaps using a >> BlockingDeque rather than your LinkedList. Generally I >> try to decouple all input and output streams: in your case your >> application is operating synchronously like the "expect" program >> (http://expect.nist.gov/) so waits (or timeouts) will need to be >> factored in. >> >> Regards, >> Michael Erskine. >> > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) > > Florian Furthermore there is this basic baud with this confusing javadoc entry: public boolean setBaudBase(int BaudBase) throws UnsupportedCommOperationException, java.io.IOException Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 before using. maybe this could explain something Florian >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/006c7425/attachment-0031.bin From jredman at ergotech.com Tue Aug 5 09:13:36 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 05 Aug 2008 09:13:36 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: Message-ID: <48986E20.3060104@ergotech.com> Trent, So two issues: 1) Technically I'm still not sure how easy/practical a layer would be. The problems are always classes like listeners, and wrapping returns of gnu.io classes. I really see it as a "delegate" type of concept. Any thoughts or ideas of the practicality of this approach? The idea is not to modify RXTX. 2) Javax. The javax namespace does seem to be in widespread use outside of Sun (the same is true for the java namespace). The classpath extensions, or some other location, should be interested in a JavaComm implementation even if it does have dependencies on RXTX. Would you have any philosophical objection to an approach like that? Of course, I suspect it might be better if someone with that authority at Sun would admit that the javax namespace is already in the wild and that there is no problem with it being used within RXTX. Jim Trent Jarvi wrote: > Hi Jim, > > I will not step into the javax.comm namespace without Sun's explicite > permission. I fully understand the pain point you are trying to address. > > In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm > Linux) - which remains an integral part of rxtx. At the time it was a win for > Sun and rxtx. > > The Sun commapi license is/was fairly clear that rxtx should not step into that > namespace. It made sense as Sun was active in that space and rxtx may go into > another namespace - it was an experiment in working with Sun. > > This may sound silly looking at something that happened almost 10 years ago. > In a community of respect which Sun helped create, there is no question about > what to do. I hope eventually Sun will step up and do a right thing too. > > I agree that this is hurting the API more than helping it. There are also > questions about how to replace the API in the long term which includes HID > support which isn't going well so far. > > Others that can't even look at Sun's javax.comm today and can look at Kaffe's > contribution to classpathx can easily work around such restrictions. > > On Mon, 4 Aug 2008, Jim Redman wrote: > >> Has there been any work/would it be possible, to layer a javacomm >> look-alike on top of the GNU code? >> >> The goal is not to move the javax code forward, but to emulate the >> "legacy" javax packages for people who still need this. >> >> Jim >> >> Trent Jarvi wrote: >>> It would be nice to work with Sun to resolve those longstanding issues. >>> But it may not be practical unless the process goes as fast and painless >>> as the grandfathering of commapi did. >>> >>> Another option may be the old kaffe extensions that moved to gnu >>> classpathx. These don't have the native libraries but should provide >>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>> >>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From sandeep at genevasoftech.com Tue Aug 5 11:18:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Tue, 05 Aug 2008 22:48:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <48988B6C.5080409@genevasoftech.com> Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. *-- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/ad20f1cb/attachment-0031.html From Martin.Oberhuber at windriver.com Tue Aug 5 13:30:17 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Tue, 5 Aug 2008 21:30:17 +0200 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Sandeep, shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on Sol7 but I've successfully run it on Sol9 and Sol10. Or is your request really about a native 64bit variant? I'm afraid that then you're out of luck since I think that quite a bit of RXTX is not yet ready for 64 bit. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Sandeep Kumar K Sent: Tuesday, August 05, 2008 7:19 PM To: rxtx at qbang.org Subject: [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so for Solaris 9 Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. -- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/81b7f988/attachment-0031.html From tjarvi at qbang.org Tue Aug 5 22:38:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 22:38:34 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 5 Aug 2008, Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built > on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid that > then > you're out of luck since I think that quite a bit of RXTX is not yet > ready > for 64 bit. > While rxtx-2.1-7 probably has problems, The CVS code should be OK for 64 bit Solaris. If it isn't, let me know and I'll find which patch is missing. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Aug 5 23:13:00 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 23:13:00 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48986E20.3060104@ergotech.com> References: <48986E20.3060104@ergotech.com> Message-ID: On Tue, 5 Aug 2008, Jim Redman wrote: > Trent, > > So two issues: > > 1) Technically I'm still not sure how easy/practical a layer would be. The > problems are always classes like listeners, and wrapping returns of gnu.io > classes. I really see it as a "delegate" type of concept. Any thoughts or > ideas of the practicality of this approach? The idea is not to modify RXTX. I have not put too much thought into this. I assume you want what rxtx 2.0 provided to tie into javax.comm implementations. More classes could be added to rxtx 2.1-7 for SPI support. Maintaining rxtx-2.0 could also be handed to someone if they like. > > 2) Javax. The javax namespace does seem to be in widespread use outside of > Sun (the same is true for the java namespace). The classpath extensions, or > some other location, should be interested in a JavaComm implementation even > if it does have dependencies on RXTX. Would you have any philosophical > objection to an approach like that? > No problems. Classpathx would be a possible place to do it. I'd suggest thinking twice about what this involves in practical terms. You would be wanting to revive the 2.0 API while Sun is at 3.0 and grandfathering the JSR. This undermines the main reason (established api) for using the javax.comm namespace and does not leave such a project in a good position. The only win I see here is maintaining support for applications that can't migrate namespaces. Not that that isn't important. At some point it is going to be less work to just edit the bytecode :) Such a javax.comm effort would also be signing up new projects that decided to use the work up for concerns they probably will not understand or expect. That probably isn't a good path to facilitate for new projects at this time. We will put a good faith effort to work well with others but keep in mind the project has limited bandwidth for such efforts. > Of course, I suspect it might be better if someone with that authority at Sun > would admit that the javax namespace is already in the wild and that there is > no problem with it being used within RXTX. > > Jim > > Trent Jarvi wrote: >> Hi Jim, >> >> I will not step into the javax.comm namespace without Sun's explicite >> permission. I fully understand the pain point you are trying to address. >> >> In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java >> Comm Linux) - which remains an integral part of rxtx. At the time it was a >> win for Sun and rxtx. >> >> The Sun commapi license is/was fairly clear that rxtx should not step into >> that namespace. It made sense as Sun was active in that space and rxtx may >> go into another namespace - it was an experiment in working with Sun. >> >> This may sound silly looking at something that happened almost 10 years >> ago. In a community of respect which Sun helped create, there is no >> question about what to do. I hope eventually Sun will step up and do a >> right thing too. >> >> I agree that this is hurting the API more than helping it. There are also >> questions about how to replace the API in the long term which includes HID >> support which isn't going well so far. >> >> Others that can't even look at Sun's javax.comm today and can look at >> Kaffe's contribution to classpathx can easily work around such >> restrictions. >> >> On Mon, 4 Aug 2008, Jim Redman wrote: >> >>> Has there been any work/would it be possible, to layer a javacomm >>> look-alike on top of the GNU code? >>> >>> The goal is not to move the javax code forward, but to emulate the >>> "legacy" javax packages for people who still need this. >>> >>> Jim >>> >>> Trent Jarvi wrote: >>>> It would be nice to work with Sun to resolve those longstanding issues. >>>> But it may not be practical unless the process goes as fast and painless >>>> as the grandfathering of commapi did. >>>> >>>> Another option may be the old kaffe extensions that moved to gnu >>>> classpathx. These don't have the native libraries but should provide >>>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>>> >>>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From sandeep at genevasoftech.com Wed Aug 6 00:03:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Wed, 06 Aug 2008 11:33:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: <48993EB8.30107@genevasoftech.com> Thank you Mr. Martin for your suggestion. The native file which is given in rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am getting the following error . Any suggestions to solve this issue. I am using Solaris SPARC 64 bit machine. ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) thrown while loading gnu.io.RXTXCommDriver Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(Unknown Source) at java.lang.ClassLoader.loadLibrary(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) at com.ReadFromModem.main(ReadFromModem.java:84) * * *Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid > that then > you're out of luck since I think that quite a bit of RXTX is not yet ready > for 64 bit. > > Cheers, > -- > *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > ------------------------------------------------------------------------ > *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On > Behalf Of *Sandeep Kumar K > *Sent:* Tuesday, August 05, 2008 7:19 PM > *To:* rxtx at qbang.org > *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so > for Solaris 9 > > Hi, > > Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 > bit machine. The librxtxSerial.so given in website is for Solaris 8. > > *-- > > Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/1e920343/attachment-0031.html From tjarvi at qbang.org Wed Aug 6 00:21:42 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 00:21:42 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <48993EB8.30107@genevasoftech.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> <48993EB8.30107@genevasoftech.com> Message-ID: Hi Sandeep You may be out of luck unless you can compile the 2.1 src in CVS (requires gnu make and gcc). But you could try the ToyBox(R)(TM) which is a collection of WiLdLy untested cross compiled 2.1-7 binaries covering everything from the ibm z series to embeded arm/ppc. To give an idea how poorly these are tested, I don't even know if z series machines have a serial port. ftp://www.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Solaris They should at least match the binary types. Actually, I think if you use the rxtx jar from CVS with that file, it should 'work' as the fix for 64 bits was in java not the native code. You could just cd rxtx*/src; javac *.java then jar -cf RXTXcomm.jar `find -name \*.class` to create the hybrid which will complain about version information a bit. On Wed, 6 Aug 2008, Sandeep Kumar K wrote: > Thank you Mr. Martin for your suggestion. The native file which is given in > rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am > getting the following error . > Any suggestions to solve this issue. > I am using Solaris SPARC 64 bit machine. > > ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar > java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 > (Possible cause: architecture word > width mismatch) thrown while loading gnu.io.RXTXCommDriver > Exception in thread "main" java.lang.UnsatisfiedLinkError: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF > class: ELFCLASS64 (Possible cause: > architecture word width mismatch) > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(Unknown Source) > at java.lang.ClassLoader.loadLibrary(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > at com.ReadFromModem.main(ReadFromModem.java:84) > > * > * > > *Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > > > Oberhuber, Martin wrote: >> Sandeep, >> shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse >> variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on >> Sol7 but I've successfully run it on Sol9 and Sol10. >> Or is your request really about a native 64bit variant? I'm afraid that >> then >> you're out of luck since I think that quite a bit of RXTX is not yet ready >> for 64 bit. >> Cheers, >> -- >> *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> ------------------------------------------------------------------------ >> *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On >> Behalf Of *Sandeep Kumar K >> *Sent:* Tuesday, August 05, 2008 7:19 PM >> *To:* rxtx at qbang.org >> *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so >> for Solaris 9 >> >> Hi, >> >> Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 >> bit machine. The librxtxSerial.so given in website is for Solaris 8. >> >> *-- >> Thanks & Regards >> >> Sandeep Kumar K >> Sr. Software Engineer >> Geneva Software Technologies >> Whitefield, Bangalore >> Mob : 9880193454* >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> From michael.erskine at ketech.com Wed Aug 6 01:39:28 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 6 Aug 2008 08:39:28 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Florian Manschwetus wrote: > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) Hi Florian, I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. Regards, Michael Erskine. From florianmanschwetus at gmx.de Wed Aug 6 02:53:16 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 06 Aug 2008 10:53:16 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Message-ID: <4899667C.6010706@gmx.de> Michael Erskine schrieb: > Florian Manschwetus wrote: >> Ok, sounds fine for the receiving problem. >> But why i have to wait after each byte when sending a command squence? >> (the for loop in send command) > > Hi Florian, > I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. > > Regards, > Michael Erskine. > correct with a terminal on the other end it works, my idea was that this basic baud has some influence. Could some one explain what it is for? Florian > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/c2b4fa84/attachment-0031.bin From rick_knight at rlknight.com Wed Aug 6 13:01:07 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:01:07 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F4F3.3020707@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > I have an application (Readerware) that uses RXTX with Javax to access the serial port. This used to work fine under previous Linux' and Java, but something has changed, I assume with Java itself , that is causing the application to fail with a link error. The application is not able to find librxtxSerialParallel.so. RXTX supplies librxtxSerial.so and librxtxParallel.so, but not librxtxSerialParallel.so. Where can I get librxtxSerialParallel.so, or do I need it? Is something else causing the lib to not be found? Thanks, Rick Knight From rick_knight at rlknight.com Wed Aug 6 13:17:55 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:17:55 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F8E3.5060400@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Thanks for the reply. The developer of the app I'm trying to use (Readerware) has sent me a copy of the comm.api and I've copied the library (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar into the proper places. When I try to run the application, I get this error... Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: /usr/lib/libSolarisSerialParallel.so: /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not little-endian (Possible cause: endianness mismatch) Caught java.lang.UnsatisfiedLinkError: com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I while loading driver com.sun.comm.SolarisDriver Is there a way around this error? Thanks again, Rick Knight From jlar310 at gmail.com Wed Aug 6 13:37:42 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 14:37:42 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899F8E3.5060400@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > The developer of the app I'm trying to use (Readerware) has sent me a > copy of the comm.api and I've copied the library > (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar > into the proper places. When I try to run the application, I get this > error... > > Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: > /usr/lib/libSolarisSerialParallel.so: > /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not > little-endian (Possible cause: endianness mismatch) > Caught java.lang.UnsatisfiedLinkError: > com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I > > while loading driver com.sun.comm.SolarisDriver > > Is there a way around this error? What host OS are you running? From your original post it looks like 32 bit Linux. The libSolarisSerialParallel.so file is for Sun Solaris and will vary depending on the underlying hardware architecture as well. Sorry for the double post Rick, but I failed to send this to the list the first time... -- Jeff From rick_knight at rlknight.com Wed Aug 6 13:44:29 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:44:29 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: <4899FF1D.9030504@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > > >> The developer of the app I'm trying to use (Readerware) has sent me a >> copy of the comm.api and I've copied the library >> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >> into the proper places. When I try to run the application, I get this >> error... >> >> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >> /usr/lib/libSolarisSerialParallel.so: >> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >> little-endian (Possible cause: endianness mismatch) >> Caught java.lang.UnsatisfiedLinkError: >> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >> >> while loading driver com.sun.comm.SolarisDriver >> >> Is there a way around this error? >> > > What host OS are you running? From your original post it looks like 32 > bit Linux. > > The libSolarisSerialParallel.so file is for Sun Solaris and will vary > depending on the underlying hardware architecture as well. > > I'm running Kubuntu Linux (debian based). It's 32 bit. Rick Knight From jlar310 at gmail.com Wed Aug 6 15:33:23 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 16:33:23 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > I don't think Sun did binary libraries for Linux in the 2.0 version. Can someone with more historical experience than I confirm that? I recently tried to port a Comm API application from Solaris sparc to Linux x86 and likewise could not get my hands on the binary libraries. I eventually just re-wrote the code to use the gnu namespace packages and rxtx 2.1. What I don't understand is why your application vendor does not provide everything you need to run their software. FYI: I have librxtxParallel.so and librxtxSerial.so installed at JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is /usr/java/default which is actually a softlink to /usr/java/jre1.6.0_05. -- Jeff From defiantlew at yahoo.com.au Wed Aug 6 16:29:33 2008 From: defiantlew at yahoo.com.au (Lew L) Date: Thu, 7 Aug 2008 08:29:33 +1000 Subject: [Rxtx] Sun's Comm API Documentation References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> Message-ID: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> As a matter of interest is the Sun Comm API documentation available somewhere? I have tried the Sun site but it seems to have been removed. Unless I have missed the documentation for RXTX? I javadocced the RXTX source but information (to me) is minimal. Somewhere I got the impression that the Sun Comm API docs is, or was, compatible with RXTX, what is the best docs to use in conjuntion with RXTX and where may the be available? Cheers Lew From rick_knight at rlknight.com Wed Aug 6 17:18:33 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:18:33 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A3149.4050306@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff I'm not sure if I posted this here or not, but when I try to build RXTX from source I get this install error... make all-am make[1]: Entering directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' make[1]: Nothing to be done for `all-am'. make[1]: Leaving directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 Can you tell me how to get past this error and get RXTX built and installed? Thanks, Rick From bboyes at systronix.com Wed Aug 6 17:40:12 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Wed, 06 Aug 2008 17:40:12 -0600 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: At 16:29 08/06/2008, Lew L wrote: >As a matter of interest is the Sun Comm API documentation available >somewhere? I have tried the Sun site but it seems to have been removed. It's in the file we have posted, link in prev email (sorry, in a huge hurry right now). Javadocs definitely there. >Unless I have missed the documentation for RXTX? I javadocced the RXTX >source but information (to me) is minimal. >Somewhere I got the impression that the Sun Comm API docs is, or was, >compatible with RXTX, what is the best docs to use in conjuntion with RXTX >and where may the be available? Yeah, this is one of my concerns/beefs. There is little documentation for RXTX and it isn't just the same as javaxcomm. I would be willing to help out writing docs for RXTX! Yes really... esp if we can fix the Bluetooth issues. best regards Bruce >Cheers >Lew > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx ------- WWW.SYSTRONIX.COM ---------- Real embedded Java and much more +1-801-534-1017 Salt Lake City, USA From rick_knight at rlknight.com Wed Aug 6 17:54:08 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:54:08 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A39A0.2090309@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff, I would like for my vendor to switch to rxtx 2.1. It would make things much easier for me. I'm not sure why he's still using the javax compatible code. He's a small operation. Re-writing the code to use gnu namespace sounds like a major overhaul. Was it? Thanks, Rick From tjarvi at qbang.org Wed Aug 6 21:35:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:35:12 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: >> >>> Jeff wrote: >>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>>> >>>> >>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things > much easier for me. I'm not sure why he's still using the javax > compatible code. He's a small operation. Re-writing the code to use gnu > namespace sounds like a major overhaul. Was it? > Hi Jeff, The changes are fairly mechanical. Imports need to change and any explicite use of the namespace needs to change such as catching an exception. The following script was made for maintaining rxtx 2.0 but can apply to other needs. It is in the contrib dir with rxtx source. #!/bin/sh # Don't use! :) # # Sat, 03 May 2003 16:45:08 Modifications from J?rg Weule # Create a ed-cmd for the change of one pattern # case $1 in gnu) X=g/javax_comm/s+javax_comm+gnu_io+g ;; javax) X=g/gnu_io/s+gnu_io+javax_comm+g ;; *) echo;echo;echo From the top rxtx directory run;echo;echo -e \\t./ChangePackage.sh gnu;echo -e \\t\\tor;echo -e \\t./ChangePackage.sh javax;echo;echo; exit 0 ;; esac # # ed will be used to keep the owner and mode of the files unchanged. # We have run the ed-script for the characters '.' '/' as well. # "tr _ $D" do the change. # find . -type f -a -print | grep -v $0 | (while read F ; do ( echo $X; echo $X| tr _ /; echo $X| tr _ .; echo w; echo q ) | ed $F 2>&1 >/dev/null done ) # # Now we do little changes at the Makefiles. Hope that all we need. # find . -name Makefile\* -a -print | (while read F ; do cat < References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: On Thu, 7 Aug 2008, Lew L wrote: > As a matter of interest is the Sun Comm API documentation available > somewhere? I have tried the Sun site but it seems to have been removed. > > Unless I have missed the documentation for RXTX? I javadocced the RXTX > source but information (to me) is minimal. > Somewhere I got the impression that the Sun Comm API docs is, or was, > compatible with RXTX, what is the best docs to use in conjuntion with RXTX > and where may the be available? > Hi Lew, The documentation on Sun's website is accurate. The changes that are problematic in 3.0 are on the backside which rxtx used to plug into. http://java.sun.com/products/javacomm/reference/api/index.html CommPortIdentifier may have some minor differences (judging by the authors notes). -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Aug 6 21:46:08 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:46:08 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > If javax.comm.properties is properly installed and you are using a 2.0 version of Sun's commapi with rxtx 2.0, you should not see the library attempt to load libSolarisSerialParallel.so. Sun CommAPI 3.0 will not work with any version of rxtx as it is hard coded to use the shared library. See the INSTALL file with rxtx-2.0 source for more help with the properties file. -- Trent Jarvi tjarvi at qbang.org From jlar310 at gmail.com Thu Aug 7 06:32:06 2008 From: jlar310 at gmail.com (Jeff) Date: Thu, 7 Aug 2008 07:32:06 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > Jeff wrote: >> >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >> wrote: >> >>> >>> Jeff wrote: >>> >>>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>> wrote: >>>> >>>> >>>> >>>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things much > easier for me. I'm not sure why he's still using the javax compatible code. > He's a small operation. Re-writing the code to use gnu namespace sounds like > a major overhaul. Was it? I found it quite easy. In fact, in order to accommodate the transition, I actually separated all of the code that deals directly with the Comm API or RXTX into a helper class. The helper class was then coded to use reflection to determine which library was available and then instantiate the necessary objects. No direct imports of either library are used. The main application just needs to get it's hands on the IO streams and need not deal directly with the libraries. Other programs may not be so simple... But this doesn't really help you unless your vendor forks over the source code... -- Jeff From rick_knight at rlknight.com Thu Aug 7 09:47:12 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Thu, 07 Aug 2008 08:47:12 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: <489B1900.10108@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >>> wrote: >>> >>> >>>> Jeff wrote: >>>> >>>> >>>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>>> copy of the comm.api and I've copied the library >>>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>>> into the proper places. When I try to run the application, I get this >>>>>> error... >>>>>> >>>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>>> /usr/lib/libSolarisSerialParallel.so: >>>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>>> little-endian (Possible cause: endianness mismatch) >>>>>> Caught java.lang.UnsatisfiedLinkError: >>>>>> >>>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>>> >>>>>> while loading driver com.sun.comm.SolarisDriver >>>>>> >>>>>> Is there a way around this error? >>>>>> >>>>>> >>>>>> >>>>> What host OS are you running? From your original post it looks like 32 >>>>> bit Linux. >>>>> >>>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>>> depending on the underlying hardware architecture as well. >>>>> >>>>> >>>>> >>>>> >>>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>>> >>>> >>>> >>> I don't think Sun did binary libraries for Linux in the 2.0 version. >>> Can someone with more historical experience than I confirm that? >>> >>> I recently tried to port a Comm API application from Solaris sparc to >>> Linux x86 and likewise could not get my hands on the binary libraries. >>> I eventually just re-wrote the code to use the gnu namespace packages >>> and rxtx 2.1. >>> >>> What I don't understand is why your application vendor does not >>> provide everything you need to run their software. >>> >>> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >>> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >>> /usr/java/default which is actually a softlink to >>> /usr/java/jre1.6.0_05. >>> >>> >>> >> Jeff, >> >> I would like for my vendor to switch to rxtx 2.1. It would make things much >> easier for me. I'm not sure why he's still using the javax compatible code. >> He's a small operation. Re-writing the code to use gnu namespace sounds like >> a major overhaul. Was it? >> > > I found it quite easy. In fact, in order to accommodate the > transition, I actually separated all of the code that deals directly > with the Comm API or RXTX into a helper class. The helper class was > then coded to use reflection to determine which library was available > and then instantiate the necessary objects. No direct imports of > either library are used. The main application just needs to get it's > hands on the IO streams and need not deal directly with the libraries. > Other programs may not be so simple... > > But this doesn't really help you unless your vendor forks over the > source code... > > Jeff, This may not help me directly, but I'm going to forward this thread to the vendor. I think he'll be open to making things work. Thanks again, Rick Knight From agusmunioz at gmail.com Thu Aug 7 16:39:51 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Thu, 7 Aug 2008 19:39:51 -0300 Subject: [Rxtx] How to send ack? Message-ID: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Hi, I'm still learning about serial communication and I have some doubts. I've got this question about how to do the following thing in rxtx. I have this hardware that connect to a PC using a serial port. These hardware receives data from a telephone line, proccess it, and then send it forward to the serial port. I've used a program named wincomm that shows what information is send it through the serial port and I have the nex behaviour: The hardware has a buffer where all data is stored, that cannot be sent it through the seria port. The program reads the first data send it by the hardware, and keep reading the same data always. There is a button in the application that says enable Ack, and when I click, then the hardware start to send all the stored information, and all the information is shown. I write a class, using rxtx that reads the serial port, and the same thing happens, it remains reading the same (first) data all the time. And I thing something like the enable Ack I'm missing. How can I do this enable Ack from my java code using rxtx? Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080807/e0a0f9a1/attachment-0029.html From ajmas at sympatico.ca Thu Aug 7 18:26:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 7 Aug 2008 20:26:41 -0400 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: <4BF42297-81E2-4BB8-A89F-1D43588379AE@sympatico.ca> On 6-Aug-08, at 19:40 , Bruce Boyes wrote: >> Unless I have missed the documentation for RXTX? I javadocced the >> RXTX >> source but information (to me) is minimal. >> Somewhere I got the impression that the Sun Comm API docs is, or was, >> compatible with RXTX, what is the best docs to use in conjuntion >> with RXTX >> and where may the be available? > > Yeah, this is one of my concerns/beefs. There is little documentation > for RXTX and it isn't just the same as javaxcomm. > > I would be willing to help out writing docs for RXTX! Yes really... > esp if we can fix the Bluetooth issues. If you want to contribute documentation then the best place to do that is the wiki. If there is anything missing or that could be improved on then please do so. If there are any points that you would like to see improved, for which you don't have the knowledge then ask on the mailing list for a volunteer. Andre From florianmanschwetus at gmx.de Fri Aug 8 03:04:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Fri, 08 Aug 2008 11:04:14 +0200 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Message-ID: <489C0C0E.2020401@gmx.de> Agustin Mu?oz schrieb: > Hi, I'm still learning about serial communication and I have some > doubts. I've got this question about how to do the following thing in rxtx. > I have this hardware that connect to a PC using a serial port. These > hardware receives data from a telephone line, proccess it, and then send > it forward to the serial port. I've used a program named wincomm that > shows what information is send it through the serial port and I have the > nex behaviour: > > The hardware has a buffer where all data is stored, that cannot be sent > it through the seria port. > The program reads the first data send it by the hardware, and keep > reading the same data always. > There is a button in the application that says enable Ack, and when I > click, then the hardware start to send all the stored information, and > all the information is shown. > > I write a class, using rxtx that reads the serial port, and the same > thing happens, it remains reading the same (first) data all the time. > And I thing something like the enable Ack I'm missing. > How can I do this enable Ack from my java code using rxtx? Afaik, a look at man ascii reveals: Okt Dez Hex Char 006 6 06 ACK So, i hope this will do the job: send(6); florian > > Thanks in advance > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/5b4965f8/attachment-0029.bin From agusmunioz at gmail.com Fri Aug 8 16:31:00 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 19:31:00 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <489C0C0E.2020401@gmx.de> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> Message-ID: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Hi Florian, thanks for the answer. By send(6) you mean to get the port OutputStream and write a 6? I try that but it didn't work. Any suggestion? Thanks On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < florianmanschwetus at gmx.de> wrote: > Agustin Mu?oz schrieb: > > Hi, I'm still learning about serial communication and I have some doubts. >> I've got this question about how to do the following thing in rxtx. >> I have this hardware that connect to a PC using a serial port. These >> hardware receives data from a telephone line, proccess it, and then send it >> forward to the serial port. I've used a program named wincomm that shows >> what information is send it through the serial port and I have the nex >> behaviour: >> >> The hardware has a buffer where all data is stored, that cannot be sent >> it through the seria port. >> The program reads the first data send it by the hardware, and keep reading >> the same data always. >> There is a button in the application that says enable Ack, and when I >> click, then the hardware start to send all the stored information, and all >> the information is shown. >> >> I write a class, using rxtx that reads the serial port, and the same thing >> happens, it remains reading the same (first) data all the time. And I thing >> something like the enable Ack I'm missing. >> How can I do this enable Ack from my java code using rxtx? >> > Afaik, a look at man ascii reveals: > Okt Dez Hex Char > 006 6 06 ACK > So, i hope this will do the job: > send(6); > > florian > >> >> Thanks in advance >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/7f3fba42/attachment-0028.html From agusmunioz at gmail.com Fri Aug 8 18:39:27 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 21:39:27 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Message-ID: <988288430808081739x7f9e7889id82591d5a9e2b4f6@mail.gmail.com> Ok, Florian, it works!! my problem was that I've been sending, through the OutputStream, the bytes of 6 as a string: out.write("6".getBytes()); but then I realized that you can write an int on an OuptuStream, so I tried that and It works: out.write(6); Thank you for the guidance!! On Fri, Aug 8, 2008 at 7:31 PM, Agustin Mu?oz wrote: > Hi Florian, thanks for the answer. By send(6) you mean to get the port > OutputStream and write a 6? > > I try that but it didn't work. > > Any suggestion? > > Thanks > > > On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < > florianmanschwetus at gmx.de> wrote: > >> Agustin Mu?oz schrieb: >> >> Hi, I'm still learning about serial communication and I have some doubts. >>> I've got this question about how to do the following thing in rxtx. >>> I have this hardware that connect to a PC using a serial port. These >>> hardware receives data from a telephone line, proccess it, and then send it >>> forward to the serial port. I've used a program named wincomm that shows >>> what information is send it through the serial port and I have the nex >>> behaviour: >>> >>> The hardware has a buffer where all data is stored, that cannot be sent >>> it through the seria port. >>> The program reads the first data send it by the hardware, and keep >>> reading the same data always. >>> There is a button in the application that says enable Ack, and when I >>> click, then the hardware start to send all the stored information, and all >>> the information is shown. >>> >>> I write a class, using rxtx that reads the serial port, and the same >>> thing happens, it remains reading the same (first) data all the time. And I >>> thing something like the enable Ack I'm missing. >>> How can I do this enable Ack from my java code using rxtx? >>> >> Afaik, a look at man ascii reveals: >> Okt Dez Hex Char >> 006 6 06 ACK >> So, i hope this will do the job: >> send(6); >> >> florian >> >>> >>> Thanks in advance >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/b918ab3d/attachment-0028.html From florianmanschwetus at gmx.de Sat Aug 9 00:45:43 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Sat, 09 Aug 2008 08:45:43 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4899667C.6010706@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> Message-ID: <489D3D17.9090209@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >> Florian Manschwetus wrote: >>> Ok, sounds fine for the receiving problem. >>> But why i have to wait after each byte when sending a command squence? >>> (the for loop in send command) >> >> Hi Florian, >> I'd imagine you probably don't! You could send all bytes in one go and >> RXTX would send them. The problem is most probably the other end: >> perhaps it has a really small buffer, some non-standard UART, or a >> crazy timing issue. If you attach a terminal to your output and send >> all the bytes of a command in one go they should appear no problem. >> >> Regards, >> Michael Erskine. >> > correct with a terminal on the other end it works, my idea was that this > basic baud has some influence. Could some one explain what it is for? > > Florian To make it more clear, my problem is that i can't use: outputStream.write(byte[]); => Beamer doesn't understand the sequence. (mostly no answer when he answers then *001) when i use this construct instead: for (int i = 0; i < command.length; i++) { this.outputStream.write(command[i]); try { Thread.sleep(25); } catch (InterruptedException e) { // TODO Auto-generated catch block e.printStackTrace(); } } it works nearly reliable. So what could it be? This Basic Baud is what exactly? Florian -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080809/692304ee/attachment-0028.bin From tjarvi at qbang.org Sat Aug 9 16:37:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Aug 2008 16:37:19 -0600 (MDT) Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489D3D17.9090209@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> <489D3D17.9090209@gmx.de> Message-ID: On Sat, 9 Aug 2008, Florian Manschwetus wrote: > Florian Manschwetus schrieb: >> Michael Erskine schrieb: >>> Florian Manschwetus wrote: >>>> Ok, sounds fine for the receiving problem. >>>> But why i have to wait after each byte when sending a command squence? >>>> (the for loop in send command) >>> >>> Hi Florian, >>> I'd imagine you probably don't! You could send all bytes in one go and >>> RXTX would send them. The problem is most probably the other end: perhaps >>> it has a really small buffer, some non-standard UART, or a crazy timing >>> issue. If you attach a terminal to your output and send all the bytes of a >>> command in one go they should appear no problem. >>> >>> Regards, >>> Michael Erskine. >>> >> correct with a terminal on the other end it works, my idea was that this >> basic baud has some influence. Could some one explain what it is for? >> >> Florian > To make it more clear, > my problem is that i can't use: > outputStream.write(byte[]); > => Beamer doesn't understand the sequence. (mostly no answer when he answers > then *001) > > when i use this construct instead: > > for (int i = 0; i < command.length; i++) { > this.outputStream.write(command[i]); > try { > Thread.sleep(25); > } catch (InterruptedException e) { > // TODO Auto-generated catch block > e.printStackTrace(); > } > } > > it works nearly reliable. > > So what could it be? This Basic Baud is what exactly? > I suspect you are using the 'moon protocol' and don't know it. RXTX enables this by default. The buffer on the other end is first in first out while reading. If the buffer is full, the bits are hand carried to the moon and burried. Then if the other side reads a couple bytes, two more bytes go into the buffer followed by more moon protocol. The resulting array of bytes the other side reads may appear to be scrambled until you go to the moon, get the bits and insert them in the right place. Flow control can prevent the default moon protocol and throttles the communiation by almost writing a byte at a time as need be. Hardware flow control is preferable but software flow control should also work. Read and write can appear to hang if the other side is not connected. This is why we don't enable them all the time. If you can't use flow control, you have to take care with the moon protocol and give the other side time to read. That is what your slower version of write is doing. -- Trent Jarvi tjarvi at qbang.org From rxtx at allenjb.me.uk Mon Aug 11 08:06:36 2008 From: rxtx at allenjb.me.uk (AllenJB) Date: Mon, 11 Aug 2008 15:06:36 +0100 Subject: [Rxtx] Disabling EV_RXFLAG Message-ID: <48A0476C.2090800@allenjb.me.uk> Hi all, I'm working with a device which does not use an EvtChar and need to disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an event mask of FD 01 00 00. The reference software I have uses FB 00 00 00. With the rxtx mask I get framing errors which I believe are caused when the EvtChar is received. Is there currently a way with rxtx (I've using rxtx from Java) to disable EV_RXFLAG? If not from Java, where would I start if I wanted to turn the EV_RXFLAG option off in the C code? I've had a grep of the rxtx source code, but I can't see where EV_RXFLAG is being set. Thanks in advance, AllenJB From tjarvi at qbang.org Mon Aug 11 14:17:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Aug 2008 14:17:27 -0600 (MDT) Subject: [Rxtx] Disabling EV_RXFLAG In-Reply-To: <48A0476C.2090800@allenjb.me.uk> References: <48A0476C.2090800@allenjb.me.uk> Message-ID: On Mon, 11 Aug 2008, AllenJB wrote: > Hi all, > > I'm working with a device which does not use an EvtChar and need to > disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an > event mask of FD 01 00 00. The reference software I have uses FB 00 00 > 00. With the rxtx mask I get framing errors which I believe are caused > when the EvtChar is received. > > Is there currently a way with rxtx (I've using rxtx from Java) to > disable EV_RXFLAG? > > If not from Java, where would I start if I wanted to turn the EV_RXFLAG > option off in the C code? I've had a grep of the rxtx source code, but I > can't see where EV_RXFLAG is being set. > > Thanks in advance, > > AllenJB Hi Allen, I'd look at termios.c::tcsetattr() and termios.c::FillDCB() -- Trent Jarvi tjarvi at qbang.org From superdadusa at gmail.com Tue Aug 12 13:57:32 2008 From: superdadusa at gmail.com (John Choi) Date: Tue, 12 Aug 2008 13:57:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. Message-ID: Hi all, Just let you all know I just start to learn Java. I have download the serial comm package and the source code from open source communities.. I was able to verify with the given message string via serial monitor. when the given message string sends to the serial port then the character return added to the end of string by default if I use "Hello World" however if I changed to something else other than "Hello, World" there is no character return add to the end of string. I thing the library download from rxtx.org has implemented for the special strings. I can do like "login\n" in the string message to make character return but I don't want to add this individual custom character for each command return in every static message string I send, Can any who have done this might help me? Basically, something like this,, Write and add function to the program write a command, Reads the respond from a serial device.. Function handles multiple messages, Write: "com open" Read: Welcome to my world" expected Write: "admin" Read: Password?, expected Write: "admin" Read: you are successfully login terminal, expected. And I need to add a separate function handler handles a character return add to the each command above. If anyone can help this I can do the reset? Thank you in advance, John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0024.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SerialIO.java Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0024.pl From Steffen.DETTMER at ingenico.com Wed Aug 13 02:16:38 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 13 Aug 2008 10:16:38 +0200 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: References: Message-ID: <20080813081638.GA25412@elberon.bln.de.ingenico.com> * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > I can do like "login\n" in the string message to make character > return but I don't want to add this individual custom character > for each command return in every static message string I send, and why not?! > Can any who have done this might help me? what's about with writing a small wrapper function adding the carriage return? However, this would be slow, because either you call write two times (very bad) or the string needs to be copied, \n appended and written (since you are using Java Performance probably isn't so critical). Personally I would write `"login\n"' and `username + "\n"' etc., because since it is part of the command it should be part of the command definition string. > Basically, something like this,, Write and add function to the program write > a command, Reads the respond from a serial device.. correctly reading a `line' is more difficult. If you cannot make assumptions about timeouts and/or you need to have low delay, you need to read byte wise. If you need to save CPU resources you might need to add some buffering layer that you can read byte-wise but that is reading blockwise with some small timeout (lets say for serial lines something around byte transmission time times three or so). > /* > * To change this template, choose Tools | Templates > * and open the template in the editor. > */ :) > package joliba; > > /** > * > * @author root > */ :) > // derived from SUN's examples in the javax.comm package > import java.io.*; > import java.util.*; > //import javax.comm.*; // for SUN's serial/parallel port libraries > import gnu.io.*; // for rxtxSerial library > > public class SerialIO implements Runnable, SerialPortEventListener { > static CommPortIdentifier portId; > static CommPortIdentifier saveportId; > static Enumeration portList; > InputStream inputStream; > SerialPort serialPort; > Thread readThread; You need a thread for your synchronous RPC-style protocol? > static String messageString = "Hello, world!"; > static OutputStream outputStream; > static boolean outputBufferEmptyFlag = false; > > public static void main(String[] args) { > boolean portFound = false; > String defaultPort; > > // determine the name of the serial port on several operating systems > String osname = System.getProperty("os.name","").toLowerCase(); > if ( osname.startsWith("windows") ) { > // windows > defaultPort = "COM1"; > } else if (osname.startsWith("linux")) { > // linux > defaultPort = "/dev/ttyS0"; > } else if ( osname.startsWith("mac") ) { > // mac > defaultPort = "????"; > } else { > System.out.println("Sorry, your operating system is not supported"); > return; > } Is such a construction recommended? Isn't there some abstraction (like COM1 working on any platform)? [...] > try { > // activate the OUTPUT_BUFFER_EMPTY notifier > serialPort.notifyOnOutputEmpty(true); > } catch (Exception e) { > System.out.println("Error setting event notification"); > System.out.println(e.toString()); > System.exit(-1); > } I doubt that -1 is defined, probably some 127 or so would be the result, maybe better simply `throw e'? > public void writetoport() { > System.out.println("Writing \""+messageString+"\" to "+serialPort.getName()); > try { > // write string to serial port > outputStream.write(messageString.getBytes()); > } catch (IOException e) {} > } maybe something like /** * Writes the given output string and an additional carriage * return to the current outputStream. */ public void writeStringToPort( /** The output string (without CR). */ String output ) throws IOException { String outputLine = output + "\n"; outputStream.write(outputLine.getBytes()); } ? > > public SerialIO() { > // initalize serial port > try { > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > } catch (PortInUseException e) {} if the port is in use, you continue? Wonder that this works in Java, I would assume serialPort beeing uninitialized which AFAIK is an error in Java. > try { > inputStream = serialPort.getInputStream(); > } catch (IOException e) {} > > try { > serialPort.addEventListener(this); > } catch (TooManyListenersException e) {} > > // activate the DATA_AVAILABLE notifier > serialPort.notifyOnDataAvailable(true); > > try { > // set port parameters > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > } catch (UnsupportedCommOperationException e) {} > > // start the read thread > readThread = new Thread(this); > readThread.start(); > > } I think in all those exception cases you can abort, because it is unlikely that ignoring those errors allow a successful continuation, so in this case maybe it would be better to add a throw clause to the method. > public void run() { > // first thing in the thread, we initialize the write operation > initwritetoport(); > try { > while (true) { > // write string to port, the serialEvent will read it > writetoport(); > Thread.sleep(1000); > } > } catch (InterruptedException e) {} > } Does this make sense? Your `SimpleReadApp' writes one and the same string each second? > public void serialEvent(SerialPortEvent event) { > switch (event.getEventType()) { > case SerialPortEvent.BI: > case SerialPortEvent.OE: > case SerialPortEvent.FE: > case SerialPortEvent.PE: > case SerialPortEvent.CD: > case SerialPortEvent.CTS: > case SerialPortEvent.DSR: > case SerialPortEvent.RI: > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > break; > case SerialPortEvent.DATA_AVAILABLE: > // we get here if data has been received > byte[] readBuffer = new byte[20]; > try { > // read data > while (inputStream.available() > 0) { > int numBytes = inputStream.read(readBuffer); > } > // print data > String result = new String(readBuffer); > System.out.println("Read: "+result); > } catch (IOException e) {} I doubt that this is correct. I would assume you will get a 20 bytes result always, if more bytes would be available they would be printed in a second line but if less bytes are read I'd assume that the buffer/result contains zero bytes from implicite readBuffer contents initialisation (zero is no string terminator in Java AFAIK). > break; > } > } > } oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From florianmanschwetus at gmx.de Wed Aug 13 06:09:31 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 13 Aug 2008 14:09:31 +0200 Subject: [Rxtx] someone has seen such errors? Message-ID: <48A2CEFB.90007@gmx.de> I mean my communication mostly works, but it is far from perfect could this be the reason? Florian Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/949b9947/attachment-0024.bin From superdadusa at gmail.com Wed Aug 13 08:40:32 2008 From: superdadusa at gmail.com (John Choi) Date: Wed, 13 Aug 2008 08:40:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: <20080813081638.GA25412@elberon.bln.de.ingenico.com> References: <20080813081638.GA25412@elberon.bln.de.ingenico.com> Message-ID: Thank you so much Steffen and I will try that suggestion. John On 8/13/08, Steffen DETTMER wrote: > > * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > > I can do like "login\n" in the string message to make character > > return but I don't want to add this individual custom character > > for each command return in every static message string I send, > > and why not?! > > > Can any who have done this might help me? > > what's about with writing a small wrapper function adding the > carriage return? > However, this would be slow, because either you call write two > times (very bad) or the string needs to be copied, \n appended > and written (since you are using Java Performance probably isn't > so critical). > > Personally I would write `"login\n"' and `username + "\n"' etc., > because since it is part of the command it should be part of the > command definition string. > > > Basically, something like this,, Write and add function to the program > write > > a command, Reads the respond from a serial device.. > > correctly reading a `line' is more difficult. If you cannot make > assumptions about timeouts and/or you need to have low delay, you > need to read byte wise. If you need to save CPU resources you > might need to add some buffering layer that you can read > byte-wise but that is reading blockwise with some small timeout > (lets say for serial lines something around byte transmission > time times three or so). > > > /* > > * To change this template, choose Tools | Templates > > * and open the template in the editor. > > */ > > :) > > > package joliba; > > > > /** > > * > > * @author root > > */ > > :) > > > // derived from SUN's examples in the javax.comm package > > import java.io.*; > > import java.util.*; > > //import javax.comm.*; // for SUN's serial/parallel port libraries > > import gnu.io.*; // for rxtxSerial library > > > > public class SerialIO implements Runnable, SerialPortEventListener { > > static CommPortIdentifier portId; > > static CommPortIdentifier saveportId; > > static Enumeration portList; > > InputStream inputStream; > > SerialPort serialPort; > > Thread readThread; > > You need a thread for your synchronous RPC-style protocol? > > > static String messageString = "Hello, world!"; > > static OutputStream outputStream; > > static boolean outputBufferEmptyFlag = false; > > > > public static void main(String[] args) { > > boolean portFound = false; > > String defaultPort; > > > > // determine the name of the serial port on several operating > systems > > String osname = System.getProperty("os.name","").toLowerCase(); > > if ( osname.startsWith("windows") ) { > > // windows > > defaultPort = "COM1"; > > } else if (osname.startsWith("linux")) { > > // linux > > defaultPort = "/dev/ttyS0"; > > } else if ( osname.startsWith("mac") ) { > > // mac > > defaultPort = "????"; > > } else { > > System.out.println("Sorry, your operating system is not > supported"); > > return; > > } > > Is such a construction recommended? Isn't there some abstraction > (like COM1 working on any platform)? > > [...] > > try { > > // activate the OUTPUT_BUFFER_EMPTY notifier > > serialPort.notifyOnOutputEmpty(true); > > } catch (Exception e) { > > System.out.println("Error setting event notification"); > > System.out.println(e.toString()); > > System.exit(-1); > > } > > I doubt that -1 is defined, probably some 127 or so would be the > result, maybe better simply `throw e'? > > > public void writetoport() { > > System.out.println("Writing \""+messageString+"\" to > "+serialPort.getName()); > > try { > > // write string to serial port > > outputStream.write(messageString.getBytes()); > > } catch (IOException e) {} > > } > > maybe something like > > /** > * Writes the given output string and an additional carriage > * return to the current outputStream. > */ > public void > writeStringToPort( > /** The output string (without CR). */ > String output > ) throws IOException > { > String outputLine = output + "\n"; > outputStream.write(outputLine.getBytes()); > } > > ? > > > > > public SerialIO() { > > // initalize serial port > > try { > > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > > } catch (PortInUseException e) {} > > if the port is in use, you continue? Wonder that this works in > Java, I would assume serialPort beeing uninitialized which AFAIK > is an error in Java. > > > try { > > inputStream = serialPort.getInputStream(); > > } catch (IOException e) {} > > > > try { > > serialPort.addEventListener(this); > > } catch (TooManyListenersException e) {} > > > > // activate the DATA_AVAILABLE notifier > > serialPort.notifyOnDataAvailable(true); > > > > try { > > // set port parameters > > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > } catch (UnsupportedCommOperationException e) {} > > > > // start the read thread > > readThread = new Thread(this); > > readThread.start(); > > > > } > > I think in all those exception cases you can abort, because it is > unlikely that ignoring those errors allow a successful > continuation, so in this case maybe it would be better to add a > throw clause to the method. > > > public void run() { > > // first thing in the thread, we initialize the write operation > > initwritetoport(); > > try { > > while (true) { > > // write string to port, the serialEvent will read it > > writetoport(); > > Thread.sleep(1000); > > } > > } catch (InterruptedException e) {} > > } > > Does this make sense? Your `SimpleReadApp' writes one and the > same string each second? > > > public void serialEvent(SerialPortEvent event) { > > switch (event.getEventType()) { > > case SerialPortEvent.BI: > > case SerialPortEvent.OE: > > case SerialPortEvent.FE: > > case SerialPortEvent.PE: > > case SerialPortEvent.CD: > > case SerialPortEvent.CTS: > > case SerialPortEvent.DSR: > > case SerialPortEvent.RI: > > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > > break; > > case SerialPortEvent.DATA_AVAILABLE: > > // we get here if data has been received > > byte[] readBuffer = new byte[20]; > > try { > > // read data > > while (inputStream.available() > 0) { > > int numBytes = inputStream.read(readBuffer); > > } > > // print data > > String result = new String(readBuffer); > > System.out.println("Read: "+result); > > } catch (IOException e) {} > > I doubt that this is correct. I would assume you will get a 20 > bytes result always, if more bytes would be available they would > be printed in a second line but if less bytes are read I'd assume > that the buffer/result contains zero bytes from implicite > readBuffer contents initialisation (zero is no string terminator > in Java AFAIK). > > > break; > > } > > } > > } > > oki, > > Steffen > > About Ingenico Throughout the world businesses rely on Ingenico for secure > and expedient electronic transaction acceptance. Ingenico products leverage > proven technology, established standards and unparalleled ergonomics to > provide optimal reliability, versatility and usability. This comprehensive > range of products is complemented by a global array of services and > partnerships, enabling businesses in a number of vertical sectors to accept > transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged > information. If you are not the addressee or authorized to receive this for > the addressee, you must not use, copy, disclose or take any action based on > this message or any information herein. If you have received this message in > error, please advise the sender immediately by reply e-mail and delete this > message. Thank you for your cooperation. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/73c4135c/attachment-0023.html From ajmas at sympatico.ca Sat Aug 16 07:15:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 09:15:41 -0400 Subject: [Rxtx] someone has seen such errors? In-Reply-To: <48A2CEFB.90007@gmx.de> References: <48A2CEFB.90007@gmx.de> Message-ID: <43B5E8DA-1D93-4D90-809B-AAF35FF724C5@sympatico.ca> On 13-Aug-08, at 08:09 , Florian Manschwetus wrote: > I mean my communication mostly works, but it is far from perfect > could this be the reason? > > Florian > > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control Judging by the error messages this looks related to the driver you are using. Do a search for the following string with you favourite search engine, it should turn up a few hits: ftdi_set_termios FAILED to set databits/stopbits/parity Andre From ajmas at sympatico.ca Sat Aug 16 19:12:04 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 21:12:04 -0400 Subject: [Rxtx] Using SerialPortEvent? Message-ID: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Hi, Could someone tell me how I should be using the SerialPortEvent? Am I meant to be waiting for data and then simply reading from the inputstream? If this is the case why no just block on an inputstream read? Andr? From tjarvi at qbang.org Sat Aug 16 19:41:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 16 Aug 2008 19:41:13 -0600 (MDT) Subject: [Rxtx] Using SerialPortEvent? In-Reply-To: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> References: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Message-ID: On Sat, 16 Aug 2008, Andre-John Mas wrote: > Hi, > > Could someone tell me how I should be using the SerialPortEvent? Am I > meant to be waiting for data and then simply reading from the > inputstream? If this is the case why no just block on an inputstream > read? > Polling for data is fine also. It really depends upon what you are trying to do. For instance, if you require x bytes before reading, you can start polling after data is available. If you read on the same thread as your GUI and are waiting for data in a read, the results may be less than desirable. Java programming is 'usually' event driven rather than polling based. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sat Aug 16 20:10:39 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 22:10:39 -0400 Subject: [Rxtx] Using SerialPortEvent? In-Reply-To: References: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Message-ID: <3E495D4C-BB28-4845-A6AB-984C9A826BDF@sympatico.ca> On 16-Aug-08, at 21:41 , Trent Jarvi wrote: > On Sat, 16 Aug 2008, Andre-John Mas wrote: > >> Hi, >> >> Could someone tell me how I should be using the SerialPortEvent? Am I >> meant to be waiting for data and then simply reading from the >> inputstream? If this is the case why no just block on an inputstream >> read? >> > > Polling for data is fine also. It really depends upon what you are > trying to do. For instance, if you require x bytes before reading, > you can start polling after data is available. If you read on the > same thread as your GUI and are waiting for data in a read, the > results may be less than desirable. > > Java programming is 'usually' event driven rather than polling based. Sounds good. I thought I would use this opportunity to provide a event based version of the TwoWaySerialComm example. Could you just validate it before I add it to the Wiki: package ajmas74.experimental; import gnu.io.CommPort; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; import gnu.io.SerialPortEvent; import gnu.io.SerialPortEventListener; import java.io.IOException; import java.io.InputStream; import java.io.OutputStream; /** * This version of the TwoWaySerialComm example makes use of the * SerialPortEventListener to avoid polling. * * @author ajmas * */ public class TwoWaySerialComm { public TwoWaySerialComm() { super(); } void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { CommPort commPort = portIdentifier.open(this.getClass().getName(),2000); if ( commPort instanceof SerialPort ) { SerialPort serialPort = (SerialPort) commPort; serialPort .setSerialPortParams (57600 ,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); (new Thread(new SerialWriter(out))).start(); serialPort.addEventListener(new SerialReader(in)); } else { System.out.println("Error: Only serial ports are handled by this example."); } } } /** * Handles the input coming from the serial port. A new line character * is treated as the end of a block in this example. */ public static class SerialReader implements SerialPortEventListener { private InputStream in; private byte[] buffer = new byte[1024]; public SerialReader ( InputStream in ) { this.in = in; } public void serialEvent(SerialPortEvent arg0) { int data; try { int len = 0; while ( ( data = in.read()) > -1 ) { if ( data != '\n' ) { break; } buffer[len++] = (byte) data; } System.out.print(new String(buffer,0,len)); } catch ( IOException e ) { e.printStackTrace(); System.exit(-1); } } } /** */ public static class SerialWriter implements Runnable { OutputStream out; public SerialWriter ( OutputStream out ) { this.out = out; } public void run () { try { int c = 0; while ( ( c = System.in.read()) > -1 ) { this.out.write(c); } } catch ( IOException e ) { e.printStackTrace(); System.exit(-1); } } } public static void main ( String[] args ) { try { (new TwoWaySerialComm()).connect("COM3"); } catch ( Exception e ) { e.printStackTrace(); } } } From lfarkas at lfarkas.org Tue Aug 19 07:32:59 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Tue, 19 Aug 2008 15:32:59 +0200 Subject: [Rxtx] JNI or CNI Message-ID: <48AACB8B.9060606@lfarkas.org> hi, what is the current recommended way to rxtx on linux JNI or it's better to use CNI? is the CNI version fully functional and the same level as the JNI? i currently try to make a rhel/centos/fedora rpm for rxtx but has many problems with the standard dir structure. yours. -- Levente "Si vis pacem para bellum!" From lfarkas at lfarkas.org Tue Aug 19 08:47:34 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Tue, 19 Aug 2008 16:47:34 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel Message-ID: <48AADD06.7040809@lfarkas.org> hi, newer or not so newer linux kernel do not contain the UTS_RELEASE so the current rxtx is not compile on the latest kernels. even if it's commented out in the cvs configure there are other places. i attcahed a patch which fix it (or at least doesn't cause error at non-debug build). ps. is there any plan to the new 2.1-8 release in the near future? there are many changes (at least the license change in all file and in this case create a diff is very difficult)? the latest release more then 2 years old:-( -- Levente "Si vis pacem para bellum!" -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-2.1-uts.patch Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080819/ab5d38ac/attachment-0017.pl From ajmas at sympatico.ca Tue Aug 19 16:21:53 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 19 Aug 2008 18:21:53 -0400 Subject: [Rxtx] Event based example Message-ID: <24735BFB-B088-4B84-8173-FE98DF63B12F@sympatico.ca> Hi, I have just posted an example of using SerialPortEventListener in the Wiki: http://rxtx.qbang.org/wiki/index.php/Event_Based_Two_Way_Communication If you see any issues please could you let me know, or makes the changes. Andre From Martin.Oberhuber at windriver.com Fri Aug 22 04:02:24 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 22 Aug 2008 12:02:24 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <48AADD06.7040809@lfarkas.org> References: <48AADD06.7040809@lfarkas.org> Message-ID: <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> Farkas, there are indeed efforts to get a new RXTX release out the door. Your experience as a package maintainer would likely be helpful during these efforts, since I'd think it makes sense to keep the patches minimal that you must make to have the source compile in your environment. What are the things that you find problematic, apart from the UTS thing that you have mentioned before? What is the timing that you have in mind for your package? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Farkas Levente > Sent: Tuesday, August 19, 2008 4:48 PM > To: rxtx at qbang.org > Subject: [Rxtx] UTS_RELEASE not defined in newer kernel > > hi, > newer or not so newer linux kernel do not contain the > UTS_RELEASE so the > current rxtx is not compile on the latest kernels. even if it's > commented out in the cvs configure there are other places. > i attcahed a patch which fix it (or at least doesn't cause error at > non-debug build). > > ps. is there any plan to the new 2.1-8 release in the near > future? there > are many changes (at least the license change in all file and in this > case create a diff is very difficult)? the latest release more then 2 > years old:-( > > -- > Levente "Si vis pacem para bellum!" > From lfarkas at lfarkas.org Fri Aug 22 04:36:26 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Fri, 22 Aug 2008 12:36:26 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> References: <48AADD06.7040809@lfarkas.org> <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> Message-ID: <48AE96AA.6090505@lfarkas.org> hi, the packages already build for fedora-9 and centos-5 and here: http://www.lfarkas.org/linux/packages/ what i've to patch, the UTS, the configure script, but it's already fixed in the cvs (in another way) and the loadlibrary. the reasons for last one can be found here: https://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_files_that_use_JNI after we test it i'd like to add these packages to fedora and epel main repository (that's why it's be useful a new release after 2 years:-) imho versions are cheap and why not just release 2.1-8? the real code changes are minimal and if something critical bug found still can release 2.1-9:-) ps. and would be better to use simple number for version like 2.1-7 rather then 2.1-7v2. Oberhuber, Martin wrote: > Farkas, > > there are indeed efforts to get a new RXTX release out the > door. Your experience as a package maintainer would likely > be helpful during these efforts, since I'd think it makes > sense to keep the patches minimal that you must make to > have the source compile in your environment. > > What are the things that you find problematic, apart from > the UTS thing that you have mentioned before? > > What is the timing that you have in mind for your package? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >> On Behalf Of Farkas Levente >> Sent: Tuesday, August 19, 2008 4:48 PM >> To: rxtx at qbang.org >> Subject: [Rxtx] UTS_RELEASE not defined in newer kernel >> >> hi, >> newer or not so newer linux kernel do not contain the >> UTS_RELEASE so the >> current rxtx is not compile on the latest kernels. even if it's >> commented out in the cvs configure there are other places. >> i attcahed a patch which fix it (or at least doesn't cause error at >> non-debug build). >> >> ps. is there any plan to the new 2.1-8 release in the near >> future? there >> are many changes (at least the license change in all file and in this >> case create a diff is very difficult)? the latest release more then 2 >> years old:-( >> >> -- >> Levente "Si vis pacem para bellum!" >> -- Levente "Si vis pacem para bellum!" From tjarvi at qbang.org Fri Aug 22 18:50:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Aug 2008 18:50:32 -0600 (MDT) Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <48AE96AA.6090505@lfarkas.org> References: <48AADD06.7040809@lfarkas.org> <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> <48AE96AA.6090505@lfarkas.org> Message-ID: Hi Farkas, The v2 was simply the second build - no code changes. We are comming out with a new release shortly. I would encourage working with distros as you are. The building of rxtx turns out to be a bottle neck in quick releases. We do want stable releases that work for a year or more but I would have no problems with quicker cycles on developing work. I would have no problem working with someone that did builds that receive less testing more often but they do have to come out for multiple platforms from this end. Thanks for the links. On Fri, 22 Aug 2008, Farkas Levente wrote: > hi, > the packages already build for fedora-9 and centos-5 and here: > http://www.lfarkas.org/linux/packages/ > what i've to patch, the UTS, the configure script, but it's already > fixed in the cvs (in another way) and the loadlibrary. the reasons for > last one can be found here: > https://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_files_that_use_JNI > after we test it i'd like to add these packages to fedora and epel main > repository (that's why it's be useful a new release after 2 years:-) > imho versions are cheap and why not just release 2.1-8? the real code > changes are minimal and if something critical bug found still can > release 2.1-9:-) > > ps. and would be better to use simple number for version like 2.1-7 > rather then 2.1-7v2. > > Oberhuber, Martin wrote: >> Farkas, >> >> there are indeed efforts to get a new RXTX release out the >> door. Your experience as a package maintainer would likely >> be helpful during these efforts, since I'd think it makes >> sense to keep the patches minimal that you must make to >> have the source compile in your environment. >> >> What are the things that you find problematic, apart from >> the UTS thing that you have mentioned before? >> >> What is the timing that you have in mind for your package? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >>> On Behalf Of Farkas Levente >>> Sent: Tuesday, August 19, 2008 4:48 PM >>> To: rxtx at qbang.org >>> Subject: [Rxtx] UTS_RELEASE not defined in newer kernel >>> >>> hi, >>> newer or not so newer linux kernel do not contain the >>> UTS_RELEASE so the >>> current rxtx is not compile on the latest kernels. even if it's >>> commented out in the cvs configure there are other places. >>> i attcahed a patch which fix it (or at least doesn't cause error at >>> non-debug build). >>> >>> ps. is there any plan to the new 2.1-8 release in the near >>> future? there >>> are many changes (at least the license change in all file and in this >>> case create a diff is very difficult)? the latest release more then 2 >>> years old:-( >>> >>> -- >>> Levente "Si vis pacem para bellum!" >>> > > > From andy at triera.net Sat Aug 23 15:17:44 2008 From: andy at triera.net (Andy Rozman) Date: Sat, 23 Aug 2008 21:17:44 +0000 Subject: [Rxtx] port not identified on FreeBSD In-Reply-To: References: Message-ID: <48B07E78.2030306@triera.net> Hi ! I have one small problem... I have started using FreeBSD in last few days and I have come accross a problem with rxtx on FreeBSD. I am using usb-to-serial converter, which is identified under FreeBSD without problem as ucom0, and creates link under /dev called ttyU0, which is correct way to be done under FreeBSD (if device would be unidentified it would be called ugen0 - as usb generic). Problem is that I say to rxtx to get my all serial ports this one is not among them. Which names are permissable under linux-like implementations? Which will be accepted as serial ports? Andy From tjarvi at qbang.org Sat Aug 23 13:57:45 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 23 Aug 2008 13:57:45 -0600 (MDT) Subject: [Rxtx] port not identified on FreeBSD In-Reply-To: <48B07E78.2030306@triera.net> References: <48B07E78.2030306@triera.net> Message-ID: On Sat, 23 Aug 2008, Andy Rozman wrote: > Hi ! > > I have one small problem... I have started using FreeBSD in last few > days and I have come accross a problem with rxtx on FreeBSD. > > I am using usb-to-serial converter, which is identified under FreeBSD > without problem as ucom0, and creates link under /dev called > ttyU0, which is correct way to be done under FreeBSD (if device would be > unidentified it would be called ugen0 - as usb generic). Problem is that > I say to rxtx to get my all serial ports this one is not among them. > Which names are permissable under linux-like implementations? Which will > be accepted as serial ports? > > Andy > Thanks Andy! We will add ttyU* to FreeBSD. For now you can use properties to enable the port. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting#How_does_rxtx_detect_ports.3F__Can_I_override_it.3F The fix: diff -u -r1.16.2.59 RXTXCommDriver.java --- RXTXCommDriver.java 18 Nov 2007 22:32:41 -0000 1.16.2.59 +++ RXTXCommDriver.java 23 Aug 2008 19:55:25 -0000 @@ -644,6 +644,7 @@ { String[] Temp = { "ttyd", //general purpose serial ports + "ttyU", //general purpose USB serial ports "cuaa", //dialout serial ports "ttyA", //Specialix SI/XIO dialin ports "cuaA", //Specialix SI/XIO dialout ports -- Trent Jarvi tjarvi at qbang.org From rick_knight at rlknight.com Mon Aug 4 13:25:10 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Mon, 04 Aug 2008 12:25:10 -0700 Subject: [Rxtx] Sun's Comm API? Message-ID: <48975796.4010600@rlknight.com> I have an application that requires the javax compatible version of RXTX and Sun's comm api. I've been able to download and extract the version of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api anywhere. Can someone tell me where I can find it? Or maybe send me a copy? Also, when I try to build RXTX, configure and make complete successfully but make install failes with this error libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 I've never come accross this error before. How can I get past it? Thanks, Rick From bboyes at systronix.com Mon Aug 4 19:10:01 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:10:01 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48975796.4010600@rlknight.com> References: <48975796.4010600@rlknight.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/cb9c6167/attachment-0033.html From bboyes at systronix.com Mon Aug 4 19:12:37 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:12:37 -0600 Subject: [Rxtx] Towards an RXTX release - CSR BT/USB chipset In-Reply-To: <488FB7E7.8000802@gmail.com> References: <460801A4097E3D4CA04CC64EE648584806C56CF0@ism-mail03.corp.ad.wrs.com> <13557-75390@sneakemail.com> <20980-23424@sneakemail.com> <488FB7E7.8000802@gmail.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/52236088/attachment-0033.html From tjarvi at qbang.org Mon Aug 4 19:42:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 19:42:21 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: On Mon, 4 Aug 2008, Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: > I have an application that requires the javax compatible > version of RXTX > and Sun's comm api. I've been able to download and extract > the version > of RXTX that I need (2.0-7pre2) but I can't find Sun's camm > api > anywhere. Can someone tell me where I can find it? Or maybe > send me a > > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm port > support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have just > a ZIP with only the .class JAR file - no source or docs), has a readme > with these comments: > > This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release.? The 2.0.3 release itself is > no longer distributed.? comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project.? The RxTx project (http://www.rxtx.org ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org) was opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support.? Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins.? Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > ? > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > I hope that is helpful! > It would be nice to work with Sun to resolve those longstanding issues. But it may not be practical unless the process goes as fast and painless as the grandfathering of commapi did. Another option may be the old kaffe extensions that moved to gnu classpathx. These don't have the native libraries but should provide the 2.0 interface and the javax.comm.properties mechansim for SPI. http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Mon Aug 4 20:23:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Mon, 04 Aug 2008 20:23:57 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4897B9BD.5070809@ergotech.com> Has there been any work/would it be possible, to layer a javacomm look-alike on top of the GNU code? The goal is not to move the javax code forward, but to emulate the "legacy" javax packages for people who still need this. Jim Trent Jarvi wrote: > On Mon, 4 Aug 2008, Bruce Boyes wrote: > >> At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible >> version of RXTX >> and Sun's comm api. I've been able to download and extract >> the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm >> api >> anywhere. Can someone tell me where I can find it? Or maybe >> send me a >> >> >> javaxcomm has had a sort of on-again off-again history. The windoze >> version has been languishing for years (literally) but there are newer >> versions for other OS's. >> >> We try to keep links on one of our help pages current: >> http://www.practicalembeddedjava.com/tools/javatools_list.html >> which gets you to here: >> http://java.sun.com/products/javacomm/ >> where it says in fact they no longer even support Windows and Mac: >> "Implementations of the API are currently available for Solaris SPARC, >> Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so >> someone could support it. But I guess that's part of the reason RXTX >> exists! >> >> So one of Sun's own products, SunSPOT, has to use RXTX to get comm port >> support. >> >> The version we use is 2.0 from 11/15/1998. I have posted it on our >> website, which is within the terms of the license agreement contained >> therein (as I understand it). >> >> The last version of javaxcomm for Windows, 2.0.3, (for which I have just >> a ZIP with only the .class JAR file - no source or docs), has a readme >> with these comments: >> >> This distribution contains the comm.jar file original part >> of the COMMAPI 2.0.3 release. The 2.0.3 release itself is >> no longer distributed. comm.jar, which contains the comm >> API java class files (eg. Sun's binary implementation of the >> interface classes), is being made available, unsupported, >> with no obligation to fix bugs, at the request of the RXTX >> project. The RxTx project (http://www.rxtx.org ), uses the >> comm.jar class files, but provides their own native library >> components to provide support for other platforms. >> >> The 2.0.3 comm.jar is being provided in this way because >> as of COMMAPI 3.x, the java binary implementation forked and >> became incompatible with the RxTx project's native code. >> Due to the lack of a clear business case, and to resource >> constraints, no additional resources are being >> provided to provide an alternative engineering solution >> at the time of writing. >> >> RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: >> >> Ultimately the COMMAPI would be better served if a Java >> Community Process JSR (http://www.jcp.org) was opened and >> the COMMAPI was rearchitected to provide a more pluggable >> framework to improve cross-platform support. Such an >> architecture would embody a better defined and better >> documented SPI interface, including a way for comm. ports >> to be revealed to the client application through the API >> via platform-aware plugins. Similarly, native code used >> to access comm port in general could be handled more >> flexibly using a plugin model, whereby on any platform, >> multiple native modules could be in use simultaneously. >> >> Since there are now various ways serial ports can be implemented >> and accessed, modular comm. port JNI native libraries would be >> of benefit insofar as removing the burden of over-generalization >> from any single native component, or inversely, by relieving the >> implicit constraint that comm. drivers be accessed only via a >> monolithic mechanism, such as the UNIX vnode interface. >> >> paul.klissner at sun.com >> 6/10/06 >> >> I hope that is helpful! >> > > It would be nice to work with Sun to resolve those longstanding issues. > But it may not be practical unless the process goes as fast and painless > as the grandfathering of commapi did. > > Another option may be the old kaffe extensions that moved to gnu > classpathx. These don't have the native libraries but should provide > the 2.0 interface and the javax.comm.properties mechansim for SPI. > > http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Mon Aug 4 21:09:15 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 21:09:15 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? Message-ID: Hi Jim, I will not step into the javax.comm namespace without Sun's explicite permission. I fully understand the pain point you are trying to address. In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm Linux) - which remains an integral part of rxtx. At the time it was a win for Sun and rxtx. The Sun commapi license is/was fairly clear that rxtx should not step into that namespace. It made sense as Sun was active in that space and rxtx may go into another namespace - it was an experiment in working with Sun. This may sound silly looking at something that happened almost 10 years ago. In a community of respect which Sun helped create, there is no question about what to do. I hope eventually Sun will step up and do a right thing too. I agree that this is hurting the API more than helping it. There are also questions about how to replace the API in the long term which includes HID support which isn't going well so far. Others that can't even look at Sun's javax.comm today and can look at Kaffe's contribution to classpathx can easily work around such restrictions. On Mon, 4 Aug 2008, Jim Redman wrote: > Has there been any work/would it be possible, to layer a javacomm > look-alike on top of the GNU code? > > The goal is not to move the javax code forward, but to emulate the > "legacy" javax packages for people who still need this. > > Jim > > Trent Jarvi wrote: >> >> It would be nice to work with Sun to resolve those longstanding issues. >> But it may not be practical unless the process goes as fast and painless >> as the grandfathering of commapi did. >> >> Another option may be the old kaffe extensions that moved to gnu >> classpathx. These don't have the native libraries but should provide >> the 2.0 interface and the javax.comm.properties mechansim for SPI. >> >> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From florianmanschwetus at gmx.de Tue Aug 5 05:04:46 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 13:04:46 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: References: <48971C1F.9020806@gmx.de> Message-ID: <489833CE.1040801@gmx.de> Just look at sendCommand in this method I have to place a Thread.sleep(20) after each byte send to get working. Even the event based receive doesn't work fine but this could be may stupidness. The specifikation document (it is on the last pages of the manual) for the beamer could be found on: http://www.optoma.co.uk/support.aspx Florian Manschwetus Trent Jarvi schrieb: > > Hi Florian > > Sorry for the top post in advance. I worry you may not see my answer > under all your code :) > > I have not received this email before. This is 500k of code which I > don't have time to read. I can spend about 5 min on each hobby email > and still get to work in the morning. I have a couple suggestions for > how to get an answer. > > First, cut out your comments and extra code so you can demonstrate the > question (I might even glance and see what is wrong then). Don't go for > a working final product. Isolate the problem using a simple program and > then ask with that as an example. If I did what you just did, I'd have > to post 3/4 of a million lines of code :) > > Second, join the rxtx mail-list and ask there. This will give you 100x > more eyes. I'll also read and try to follow. > > -- > taj > > > > On Mon, 4 Aug 2008, Florian Manschwetus wrote: > >> It could be that my university account is blocked by filters so >> resending from here. >> >> >> Topic is to control Optoma HD80 beamer using rs232 serial chat. >> This code is able to detect power state and switch the beamer on / off. >> connected is the beamer using a digitus usb 2.0 serial adapter with an >> FT232 USB-Serial adapter the systems architecture is amd64. >> >> Please take a look in the sendCommand routine i have to place theire >> those Thread.sleep to get it working. >> Now the question is this correct or is there a better way to get this >> working correctly? >> >> In the javadoc coming with the install i found this: >> setBaudBase >> >> public boolean setBaudBase(int BaudBase) >> throws UnsupportedCommOperationException, >> java.io.IOException >> >> Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 >> before using. >> >> could this explain the error? >> I attached my java source and the protocol description for the beamer >> (available on vendor website). >> >> thx, >> Florian Manschwetus >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: TestRS232.java Type: text/x-java Size: 9143 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0066.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0067.bin From michael.erskine at ketech.com Tue Aug 5 05:53:49 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Tue, 5 Aug 2008 12:53:49 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489833CE.1040801@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> > Just look at sendCommand in this method I have to place a > Thread.sleep(20) after each byte send to get working. Even the event > based receive doesn't work fine but this could be may stupidness. Hi Florian, Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. Regards, Michael Erskine. From florianmanschwetus at gmx.de Tue Aug 5 07:28:15 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:28:15 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> Message-ID: <4898556F.8000208@gmx.de> Michael Erskine schrieb: >> Just look at sendCommand in this method I have to place a >> Thread.sleep(20) after each byte send to get working. Even the event >> based receive doesn't work fine but this could be may stupidness. > > Hi Florian, > > Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. > > Regards, > Michael Erskine. > Ok, sounds fine for the receiving problem. But why i have to wait after each byte when sending a command squence? (the for loop in send command) Florian > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/284f350c/attachment-0032.bin From florianmanschwetus at gmx.de Tue Aug 5 07:44:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:44:14 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <4898592E.2020908@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >>> Just look at sendCommand in this method I have to place a >>> Thread.sleep(20) after each byte send to get working. Even the event >>> based receive doesn't work fine but this could be may stupidness. >> >> Hi Florian, >> >> Yes, naturally you'll have to wait for a response from the other end. >> Why not wait for notification from the event thread perhaps using a >> BlockingDeque rather than your LinkedList. Generally I >> try to decouple all input and output streams: in your case your >> application is operating synchronously like the "expect" program >> (http://expect.nist.gov/) so waits (or timeouts) will need to be >> factored in. >> >> Regards, >> Michael Erskine. >> > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) > > Florian Furthermore there is this basic baud with this confusing javadoc entry: public boolean setBaudBase(int BaudBase) throws UnsupportedCommOperationException, java.io.IOException Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 before using. maybe this could explain something Florian >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/006c7425/attachment-0032.bin From jredman at ergotech.com Tue Aug 5 09:13:36 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 05 Aug 2008 09:13:36 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: Message-ID: <48986E20.3060104@ergotech.com> Trent, So two issues: 1) Technically I'm still not sure how easy/practical a layer would be. The problems are always classes like listeners, and wrapping returns of gnu.io classes. I really see it as a "delegate" type of concept. Any thoughts or ideas of the practicality of this approach? The idea is not to modify RXTX. 2) Javax. The javax namespace does seem to be in widespread use outside of Sun (the same is true for the java namespace). The classpath extensions, or some other location, should be interested in a JavaComm implementation even if it does have dependencies on RXTX. Would you have any philosophical objection to an approach like that? Of course, I suspect it might be better if someone with that authority at Sun would admit that the javax namespace is already in the wild and that there is no problem with it being used within RXTX. Jim Trent Jarvi wrote: > Hi Jim, > > I will not step into the javax.comm namespace without Sun's explicite > permission. I fully understand the pain point you are trying to address. > > In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm > Linux) - which remains an integral part of rxtx. At the time it was a win for > Sun and rxtx. > > The Sun commapi license is/was fairly clear that rxtx should not step into that > namespace. It made sense as Sun was active in that space and rxtx may go into > another namespace - it was an experiment in working with Sun. > > This may sound silly looking at something that happened almost 10 years ago. > In a community of respect which Sun helped create, there is no question about > what to do. I hope eventually Sun will step up and do a right thing too. > > I agree that this is hurting the API more than helping it. There are also > questions about how to replace the API in the long term which includes HID > support which isn't going well so far. > > Others that can't even look at Sun's javax.comm today and can look at Kaffe's > contribution to classpathx can easily work around such restrictions. > > On Mon, 4 Aug 2008, Jim Redman wrote: > >> Has there been any work/would it be possible, to layer a javacomm >> look-alike on top of the GNU code? >> >> The goal is not to move the javax code forward, but to emulate the >> "legacy" javax packages for people who still need this. >> >> Jim >> >> Trent Jarvi wrote: >>> It would be nice to work with Sun to resolve those longstanding issues. >>> But it may not be practical unless the process goes as fast and painless >>> as the grandfathering of commapi did. >>> >>> Another option may be the old kaffe extensions that moved to gnu >>> classpathx. These don't have the native libraries but should provide >>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>> >>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From sandeep at genevasoftech.com Tue Aug 5 11:18:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Tue, 05 Aug 2008 22:48:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <48988B6C.5080409@genevasoftech.com> Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. *-- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/ad20f1cb/attachment-0032.html From Martin.Oberhuber at windriver.com Tue Aug 5 13:30:17 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Tue, 5 Aug 2008 21:30:17 +0200 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Sandeep, shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on Sol7 but I've successfully run it on Sol9 and Sol10. Or is your request really about a native 64bit variant? I'm afraid that then you're out of luck since I think that quite a bit of RXTX is not yet ready for 64 bit. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Sandeep Kumar K Sent: Tuesday, August 05, 2008 7:19 PM To: rxtx at qbang.org Subject: [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so for Solaris 9 Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. -- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/81b7f988/attachment-0032.html From tjarvi at qbang.org Tue Aug 5 22:38:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 22:38:34 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 5 Aug 2008, Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built > on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid that > then > you're out of luck since I think that quite a bit of RXTX is not yet > ready > for 64 bit. > While rxtx-2.1-7 probably has problems, The CVS code should be OK for 64 bit Solaris. If it isn't, let me know and I'll find which patch is missing. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Aug 5 23:13:00 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 23:13:00 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48986E20.3060104@ergotech.com> References: <48986E20.3060104@ergotech.com> Message-ID: On Tue, 5 Aug 2008, Jim Redman wrote: > Trent, > > So two issues: > > 1) Technically I'm still not sure how easy/practical a layer would be. The > problems are always classes like listeners, and wrapping returns of gnu.io > classes. I really see it as a "delegate" type of concept. Any thoughts or > ideas of the practicality of this approach? The idea is not to modify RXTX. I have not put too much thought into this. I assume you want what rxtx 2.0 provided to tie into javax.comm implementations. More classes could be added to rxtx 2.1-7 for SPI support. Maintaining rxtx-2.0 could also be handed to someone if they like. > > 2) Javax. The javax namespace does seem to be in widespread use outside of > Sun (the same is true for the java namespace). The classpath extensions, or > some other location, should be interested in a JavaComm implementation even > if it does have dependencies on RXTX. Would you have any philosophical > objection to an approach like that? > No problems. Classpathx would be a possible place to do it. I'd suggest thinking twice about what this involves in practical terms. You would be wanting to revive the 2.0 API while Sun is at 3.0 and grandfathering the JSR. This undermines the main reason (established api) for using the javax.comm namespace and does not leave such a project in a good position. The only win I see here is maintaining support for applications that can't migrate namespaces. Not that that isn't important. At some point it is going to be less work to just edit the bytecode :) Such a javax.comm effort would also be signing up new projects that decided to use the work up for concerns they probably will not understand or expect. That probably isn't a good path to facilitate for new projects at this time. We will put a good faith effort to work well with others but keep in mind the project has limited bandwidth for such efforts. > Of course, I suspect it might be better if someone with that authority at Sun > would admit that the javax namespace is already in the wild and that there is > no problem with it being used within RXTX. > > Jim > > Trent Jarvi wrote: >> Hi Jim, >> >> I will not step into the javax.comm namespace without Sun's explicite >> permission. I fully understand the pain point you are trying to address. >> >> In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java >> Comm Linux) - which remains an integral part of rxtx. At the time it was a >> win for Sun and rxtx. >> >> The Sun commapi license is/was fairly clear that rxtx should not step into >> that namespace. It made sense as Sun was active in that space and rxtx may >> go into another namespace - it was an experiment in working with Sun. >> >> This may sound silly looking at something that happened almost 10 years >> ago. In a community of respect which Sun helped create, there is no >> question about what to do. I hope eventually Sun will step up and do a >> right thing too. >> >> I agree that this is hurting the API more than helping it. There are also >> questions about how to replace the API in the long term which includes HID >> support which isn't going well so far. >> >> Others that can't even look at Sun's javax.comm today and can look at >> Kaffe's contribution to classpathx can easily work around such >> restrictions. >> >> On Mon, 4 Aug 2008, Jim Redman wrote: >> >>> Has there been any work/would it be possible, to layer a javacomm >>> look-alike on top of the GNU code? >>> >>> The goal is not to move the javax code forward, but to emulate the >>> "legacy" javax packages for people who still need this. >>> >>> Jim >>> >>> Trent Jarvi wrote: >>>> It would be nice to work with Sun to resolve those longstanding issues. >>>> But it may not be practical unless the process goes as fast and painless >>>> as the grandfathering of commapi did. >>>> >>>> Another option may be the old kaffe extensions that moved to gnu >>>> classpathx. These don't have the native libraries but should provide >>>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>>> >>>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From sandeep at genevasoftech.com Wed Aug 6 00:03:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Wed, 06 Aug 2008 11:33:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: <48993EB8.30107@genevasoftech.com> Thank you Mr. Martin for your suggestion. The native file which is given in rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am getting the following error . Any suggestions to solve this issue. I am using Solaris SPARC 64 bit machine. ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) thrown while loading gnu.io.RXTXCommDriver Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(Unknown Source) at java.lang.ClassLoader.loadLibrary(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) at com.ReadFromModem.main(ReadFromModem.java:84) * * *Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid > that then > you're out of luck since I think that quite a bit of RXTX is not yet ready > for 64 bit. > > Cheers, > -- > *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > ------------------------------------------------------------------------ > *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On > Behalf Of *Sandeep Kumar K > *Sent:* Tuesday, August 05, 2008 7:19 PM > *To:* rxtx at qbang.org > *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so > for Solaris 9 > > Hi, > > Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 > bit machine. The librxtxSerial.so given in website is for Solaris 8. > > *-- > > Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/1e920343/attachment-0032.html From tjarvi at qbang.org Wed Aug 6 00:21:42 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 00:21:42 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <48993EB8.30107@genevasoftech.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> <48993EB8.30107@genevasoftech.com> Message-ID: Hi Sandeep You may be out of luck unless you can compile the 2.1 src in CVS (requires gnu make and gcc). But you could try the ToyBox(R)(TM) which is a collection of WiLdLy untested cross compiled 2.1-7 binaries covering everything from the ibm z series to embeded arm/ppc. To give an idea how poorly these are tested, I don't even know if z series machines have a serial port. ftp://www.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Solaris They should at least match the binary types. Actually, I think if you use the rxtx jar from CVS with that file, it should 'work' as the fix for 64 bits was in java not the native code. You could just cd rxtx*/src; javac *.java then jar -cf RXTXcomm.jar `find -name \*.class` to create the hybrid which will complain about version information a bit. On Wed, 6 Aug 2008, Sandeep Kumar K wrote: > Thank you Mr. Martin for your suggestion. The native file which is given in > rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am > getting the following error . > Any suggestions to solve this issue. > I am using Solaris SPARC 64 bit machine. > > ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar > java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 > (Possible cause: architecture word > width mismatch) thrown while loading gnu.io.RXTXCommDriver > Exception in thread "main" java.lang.UnsatisfiedLinkError: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF > class: ELFCLASS64 (Possible cause: > architecture word width mismatch) > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(Unknown Source) > at java.lang.ClassLoader.loadLibrary(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > at com.ReadFromModem.main(ReadFromModem.java:84) > > * > * > > *Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > > > Oberhuber, Martin wrote: >> Sandeep, >> shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse >> variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on >> Sol7 but I've successfully run it on Sol9 and Sol10. >> Or is your request really about a native 64bit variant? I'm afraid that >> then >> you're out of luck since I think that quite a bit of RXTX is not yet ready >> for 64 bit. >> Cheers, >> -- >> *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> ------------------------------------------------------------------------ >> *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On >> Behalf Of *Sandeep Kumar K >> *Sent:* Tuesday, August 05, 2008 7:19 PM >> *To:* rxtx at qbang.org >> *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so >> for Solaris 9 >> >> Hi, >> >> Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 >> bit machine. The librxtxSerial.so given in website is for Solaris 8. >> >> *-- >> Thanks & Regards >> >> Sandeep Kumar K >> Sr. Software Engineer >> Geneva Software Technologies >> Whitefield, Bangalore >> Mob : 9880193454* >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> From michael.erskine at ketech.com Wed Aug 6 01:39:28 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 6 Aug 2008 08:39:28 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Florian Manschwetus wrote: > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) Hi Florian, I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. Regards, Michael Erskine. From florianmanschwetus at gmx.de Wed Aug 6 02:53:16 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 06 Aug 2008 10:53:16 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Message-ID: <4899667C.6010706@gmx.de> Michael Erskine schrieb: > Florian Manschwetus wrote: >> Ok, sounds fine for the receiving problem. >> But why i have to wait after each byte when sending a command squence? >> (the for loop in send command) > > Hi Florian, > I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. > > Regards, > Michael Erskine. > correct with a terminal on the other end it works, my idea was that this basic baud has some influence. Could some one explain what it is for? Florian > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/c2b4fa84/attachment-0032.bin From rick_knight at rlknight.com Wed Aug 6 13:01:07 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:01:07 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F4F3.3020707@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > I have an application (Readerware) that uses RXTX with Javax to access the serial port. This used to work fine under previous Linux' and Java, but something has changed, I assume with Java itself , that is causing the application to fail with a link error. The application is not able to find librxtxSerialParallel.so. RXTX supplies librxtxSerial.so and librxtxParallel.so, but not librxtxSerialParallel.so. Where can I get librxtxSerialParallel.so, or do I need it? Is something else causing the lib to not be found? Thanks, Rick Knight From rick_knight at rlknight.com Wed Aug 6 13:17:55 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:17:55 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F8E3.5060400@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Thanks for the reply. The developer of the app I'm trying to use (Readerware) has sent me a copy of the comm.api and I've copied the library (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar into the proper places. When I try to run the application, I get this error... Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: /usr/lib/libSolarisSerialParallel.so: /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not little-endian (Possible cause: endianness mismatch) Caught java.lang.UnsatisfiedLinkError: com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I while loading driver com.sun.comm.SolarisDriver Is there a way around this error? Thanks again, Rick Knight From jlar310 at gmail.com Wed Aug 6 13:37:42 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 14:37:42 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899F8E3.5060400@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > The developer of the app I'm trying to use (Readerware) has sent me a > copy of the comm.api and I've copied the library > (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar > into the proper places. When I try to run the application, I get this > error... > > Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: > /usr/lib/libSolarisSerialParallel.so: > /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not > little-endian (Possible cause: endianness mismatch) > Caught java.lang.UnsatisfiedLinkError: > com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I > > while loading driver com.sun.comm.SolarisDriver > > Is there a way around this error? What host OS are you running? From your original post it looks like 32 bit Linux. The libSolarisSerialParallel.so file is for Sun Solaris and will vary depending on the underlying hardware architecture as well. Sorry for the double post Rick, but I failed to send this to the list the first time... -- Jeff From rick_knight at rlknight.com Wed Aug 6 13:44:29 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:44:29 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: <4899FF1D.9030504@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > > >> The developer of the app I'm trying to use (Readerware) has sent me a >> copy of the comm.api and I've copied the library >> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >> into the proper places. When I try to run the application, I get this >> error... >> >> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >> /usr/lib/libSolarisSerialParallel.so: >> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >> little-endian (Possible cause: endianness mismatch) >> Caught java.lang.UnsatisfiedLinkError: >> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >> >> while loading driver com.sun.comm.SolarisDriver >> >> Is there a way around this error? >> > > What host OS are you running? From your original post it looks like 32 > bit Linux. > > The libSolarisSerialParallel.so file is for Sun Solaris and will vary > depending on the underlying hardware architecture as well. > > I'm running Kubuntu Linux (debian based). It's 32 bit. Rick Knight From jlar310 at gmail.com Wed Aug 6 15:33:23 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 16:33:23 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > I don't think Sun did binary libraries for Linux in the 2.0 version. Can someone with more historical experience than I confirm that? I recently tried to port a Comm API application from Solaris sparc to Linux x86 and likewise could not get my hands on the binary libraries. I eventually just re-wrote the code to use the gnu namespace packages and rxtx 2.1. What I don't understand is why your application vendor does not provide everything you need to run their software. FYI: I have librxtxParallel.so and librxtxSerial.so installed at JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is /usr/java/default which is actually a softlink to /usr/java/jre1.6.0_05. -- Jeff From defiantlew at yahoo.com.au Wed Aug 6 16:29:33 2008 From: defiantlew at yahoo.com.au (Lew L) Date: Thu, 7 Aug 2008 08:29:33 +1000 Subject: [Rxtx] Sun's Comm API Documentation References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> Message-ID: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> As a matter of interest is the Sun Comm API documentation available somewhere? I have tried the Sun site but it seems to have been removed. Unless I have missed the documentation for RXTX? I javadocced the RXTX source but information (to me) is minimal. Somewhere I got the impression that the Sun Comm API docs is, or was, compatible with RXTX, what is the best docs to use in conjuntion with RXTX and where may the be available? Cheers Lew From rick_knight at rlknight.com Wed Aug 6 17:18:33 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:18:33 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A3149.4050306@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff I'm not sure if I posted this here or not, but when I try to build RXTX from source I get this install error... make all-am make[1]: Entering directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' make[1]: Nothing to be done for `all-am'. make[1]: Leaving directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 Can you tell me how to get past this error and get RXTX built and installed? Thanks, Rick From bboyes at systronix.com Wed Aug 6 17:40:12 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Wed, 06 Aug 2008 17:40:12 -0600 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: At 16:29 08/06/2008, Lew L wrote: >As a matter of interest is the Sun Comm API documentation available >somewhere? I have tried the Sun site but it seems to have been removed. It's in the file we have posted, link in prev email (sorry, in a huge hurry right now). Javadocs definitely there. >Unless I have missed the documentation for RXTX? I javadocced the RXTX >source but information (to me) is minimal. >Somewhere I got the impression that the Sun Comm API docs is, or was, >compatible with RXTX, what is the best docs to use in conjuntion with RXTX >and where may the be available? Yeah, this is one of my concerns/beefs. There is little documentation for RXTX and it isn't just the same as javaxcomm. I would be willing to help out writing docs for RXTX! Yes really... esp if we can fix the Bluetooth issues. best regards Bruce >Cheers >Lew > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx ------- WWW.SYSTRONIX.COM ---------- Real embedded Java and much more +1-801-534-1017 Salt Lake City, USA From rick_knight at rlknight.com Wed Aug 6 17:54:08 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:54:08 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A39A0.2090309@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff, I would like for my vendor to switch to rxtx 2.1. It would make things much easier for me. I'm not sure why he's still using the javax compatible code. He's a small operation. Re-writing the code to use gnu namespace sounds like a major overhaul. Was it? Thanks, Rick From tjarvi at qbang.org Wed Aug 6 21:35:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:35:12 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: >> >>> Jeff wrote: >>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>>> >>>> >>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things > much easier for me. I'm not sure why he's still using the javax > compatible code. He's a small operation. Re-writing the code to use gnu > namespace sounds like a major overhaul. Was it? > Hi Jeff, The changes are fairly mechanical. Imports need to change and any explicite use of the namespace needs to change such as catching an exception. The following script was made for maintaining rxtx 2.0 but can apply to other needs. It is in the contrib dir with rxtx source. #!/bin/sh # Don't use! :) # # Sat, 03 May 2003 16:45:08 Modifications from J?rg Weule # Create a ed-cmd for the change of one pattern # case $1 in gnu) X=g/javax_comm/s+javax_comm+gnu_io+g ;; javax) X=g/gnu_io/s+gnu_io+javax_comm+g ;; *) echo;echo;echo From the top rxtx directory run;echo;echo -e \\t./ChangePackage.sh gnu;echo -e \\t\\tor;echo -e \\t./ChangePackage.sh javax;echo;echo; exit 0 ;; esac # # ed will be used to keep the owner and mode of the files unchanged. # We have run the ed-script for the characters '.' '/' as well. # "tr _ $D" do the change. # find . -type f -a -print | grep -v $0 | (while read F ; do ( echo $X; echo $X| tr _ /; echo $X| tr _ .; echo w; echo q ) | ed $F 2>&1 >/dev/null done ) # # Now we do little changes at the Makefiles. Hope that all we need. # find . -name Makefile\* -a -print | (while read F ; do cat < References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: On Thu, 7 Aug 2008, Lew L wrote: > As a matter of interest is the Sun Comm API documentation available > somewhere? I have tried the Sun site but it seems to have been removed. > > Unless I have missed the documentation for RXTX? I javadocced the RXTX > source but information (to me) is minimal. > Somewhere I got the impression that the Sun Comm API docs is, or was, > compatible with RXTX, what is the best docs to use in conjuntion with RXTX > and where may the be available? > Hi Lew, The documentation on Sun's website is accurate. The changes that are problematic in 3.0 are on the backside which rxtx used to plug into. http://java.sun.com/products/javacomm/reference/api/index.html CommPortIdentifier may have some minor differences (judging by the authors notes). -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Aug 6 21:46:08 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:46:08 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > If javax.comm.properties is properly installed and you are using a 2.0 version of Sun's commapi with rxtx 2.0, you should not see the library attempt to load libSolarisSerialParallel.so. Sun CommAPI 3.0 will not work with any version of rxtx as it is hard coded to use the shared library. See the INSTALL file with rxtx-2.0 source for more help with the properties file. -- Trent Jarvi tjarvi at qbang.org From jlar310 at gmail.com Thu Aug 7 06:32:06 2008 From: jlar310 at gmail.com (Jeff) Date: Thu, 7 Aug 2008 07:32:06 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > Jeff wrote: >> >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >> wrote: >> >>> >>> Jeff wrote: >>> >>>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>> wrote: >>>> >>>> >>>> >>>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things much > easier for me. I'm not sure why he's still using the javax compatible code. > He's a small operation. Re-writing the code to use gnu namespace sounds like > a major overhaul. Was it? I found it quite easy. In fact, in order to accommodate the transition, I actually separated all of the code that deals directly with the Comm API or RXTX into a helper class. The helper class was then coded to use reflection to determine which library was available and then instantiate the necessary objects. No direct imports of either library are used. The main application just needs to get it's hands on the IO streams and need not deal directly with the libraries. Other programs may not be so simple... But this doesn't really help you unless your vendor forks over the source code... -- Jeff From rick_knight at rlknight.com Thu Aug 7 09:47:12 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Thu, 07 Aug 2008 08:47:12 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: <489B1900.10108@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >>> wrote: >>> >>> >>>> Jeff wrote: >>>> >>>> >>>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>>> copy of the comm.api and I've copied the library >>>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>>> into the proper places. When I try to run the application, I get this >>>>>> error... >>>>>> >>>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>>> /usr/lib/libSolarisSerialParallel.so: >>>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>>> little-endian (Possible cause: endianness mismatch) >>>>>> Caught java.lang.UnsatisfiedLinkError: >>>>>> >>>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>>> >>>>>> while loading driver com.sun.comm.SolarisDriver >>>>>> >>>>>> Is there a way around this error? >>>>>> >>>>>> >>>>>> >>>>> What host OS are you running? From your original post it looks like 32 >>>>> bit Linux. >>>>> >>>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>>> depending on the underlying hardware architecture as well. >>>>> >>>>> >>>>> >>>>> >>>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>>> >>>> >>>> >>> I don't think Sun did binary libraries for Linux in the 2.0 version. >>> Can someone with more historical experience than I confirm that? >>> >>> I recently tried to port a Comm API application from Solaris sparc to >>> Linux x86 and likewise could not get my hands on the binary libraries. >>> I eventually just re-wrote the code to use the gnu namespace packages >>> and rxtx 2.1. >>> >>> What I don't understand is why your application vendor does not >>> provide everything you need to run their software. >>> >>> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >>> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >>> /usr/java/default which is actually a softlink to >>> /usr/java/jre1.6.0_05. >>> >>> >>> >> Jeff, >> >> I would like for my vendor to switch to rxtx 2.1. It would make things much >> easier for me. I'm not sure why he's still using the javax compatible code. >> He's a small operation. Re-writing the code to use gnu namespace sounds like >> a major overhaul. Was it? >> > > I found it quite easy. In fact, in order to accommodate the > transition, I actually separated all of the code that deals directly > with the Comm API or RXTX into a helper class. The helper class was > then coded to use reflection to determine which library was available > and then instantiate the necessary objects. No direct imports of > either library are used. The main application just needs to get it's > hands on the IO streams and need not deal directly with the libraries. > Other programs may not be so simple... > > But this doesn't really help you unless your vendor forks over the > source code... > > Jeff, This may not help me directly, but I'm going to forward this thread to the vendor. I think he'll be open to making things work. Thanks again, Rick Knight From agusmunioz at gmail.com Thu Aug 7 16:39:51 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Thu, 7 Aug 2008 19:39:51 -0300 Subject: [Rxtx] How to send ack? Message-ID: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Hi, I'm still learning about serial communication and I have some doubts. I've got this question about how to do the following thing in rxtx. I have this hardware that connect to a PC using a serial port. These hardware receives data from a telephone line, proccess it, and then send it forward to the serial port. I've used a program named wincomm that shows what information is send it through the serial port and I have the nex behaviour: The hardware has a buffer where all data is stored, that cannot be sent it through the seria port. The program reads the first data send it by the hardware, and keep reading the same data always. There is a button in the application that says enable Ack, and when I click, then the hardware start to send all the stored information, and all the information is shown. I write a class, using rxtx that reads the serial port, and the same thing happens, it remains reading the same (first) data all the time. And I thing something like the enable Ack I'm missing. How can I do this enable Ack from my java code using rxtx? Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080807/e0a0f9a1/attachment-0030.html From ajmas at sympatico.ca Thu Aug 7 18:26:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 7 Aug 2008 20:26:41 -0400 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: <4BF42297-81E2-4BB8-A89F-1D43588379AE@sympatico.ca> On 6-Aug-08, at 19:40 , Bruce Boyes wrote: >> Unless I have missed the documentation for RXTX? I javadocced the >> RXTX >> source but information (to me) is minimal. >> Somewhere I got the impression that the Sun Comm API docs is, or was, >> compatible with RXTX, what is the best docs to use in conjuntion >> with RXTX >> and where may the be available? > > Yeah, this is one of my concerns/beefs. There is little documentation > for RXTX and it isn't just the same as javaxcomm. > > I would be willing to help out writing docs for RXTX! Yes really... > esp if we can fix the Bluetooth issues. If you want to contribute documentation then the best place to do that is the wiki. If there is anything missing or that could be improved on then please do so. If there are any points that you would like to see improved, for which you don't have the knowledge then ask on the mailing list for a volunteer. Andre From florianmanschwetus at gmx.de Fri Aug 8 03:04:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Fri, 08 Aug 2008 11:04:14 +0200 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Message-ID: <489C0C0E.2020401@gmx.de> Agustin Mu?oz schrieb: > Hi, I'm still learning about serial communication and I have some > doubts. I've got this question about how to do the following thing in rxtx. > I have this hardware that connect to a PC using a serial port. These > hardware receives data from a telephone line, proccess it, and then send > it forward to the serial port. I've used a program named wincomm that > shows what information is send it through the serial port and I have the > nex behaviour: > > The hardware has a buffer where all data is stored, that cannot be sent > it through the seria port. > The program reads the first data send it by the hardware, and keep > reading the same data always. > There is a button in the application that says enable Ack, and when I > click, then the hardware start to send all the stored information, and > all the information is shown. > > I write a class, using rxtx that reads the serial port, and the same > thing happens, it remains reading the same (first) data all the time. > And I thing something like the enable Ack I'm missing. > How can I do this enable Ack from my java code using rxtx? Afaik, a look at man ascii reveals: Okt Dez Hex Char 006 6 06 ACK So, i hope this will do the job: send(6); florian > > Thanks in advance > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/5b4965f8/attachment-0030.bin From agusmunioz at gmail.com Fri Aug 8 16:31:00 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 19:31:00 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <489C0C0E.2020401@gmx.de> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> Message-ID: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Hi Florian, thanks for the answer. By send(6) you mean to get the port OutputStream and write a 6? I try that but it didn't work. Any suggestion? Thanks On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < florianmanschwetus at gmx.de> wrote: > Agustin Mu?oz schrieb: > > Hi, I'm still learning about serial communication and I have some doubts. >> I've got this question about how to do the following thing in rxtx. >> I have this hardware that connect to a PC using a serial port. These >> hardware receives data from a telephone line, proccess it, and then send it >> forward to the serial port. I've used a program named wincomm that shows >> what information is send it through the serial port and I have the nex >> behaviour: >> >> The hardware has a buffer where all data is stored, that cannot be sent >> it through the seria port. >> The program reads the first data send it by the hardware, and keep reading >> the same data always. >> There is a button in the application that says enable Ack, and when I >> click, then the hardware start to send all the stored information, and all >> the information is shown. >> >> I write a class, using rxtx that reads the serial port, and the same thing >> happens, it remains reading the same (first) data all the time. And I thing >> something like the enable Ack I'm missing. >> How can I do this enable Ack from my java code using rxtx? >> > Afaik, a look at man ascii reveals: > Okt Dez Hex Char > 006 6 06 ACK > So, i hope this will do the job: > send(6); > > florian > >> >> Thanks in advance >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/7f3fba42/attachment-0029.html From agusmunioz at gmail.com Fri Aug 8 18:39:27 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 21:39:27 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Message-ID: <988288430808081739x7f9e7889id82591d5a9e2b4f6@mail.gmail.com> Ok, Florian, it works!! my problem was that I've been sending, through the OutputStream, the bytes of 6 as a string: out.write("6".getBytes()); but then I realized that you can write an int on an OuptuStream, so I tried that and It works: out.write(6); Thank you for the guidance!! On Fri, Aug 8, 2008 at 7:31 PM, Agustin Mu?oz wrote: > Hi Florian, thanks for the answer. By send(6) you mean to get the port > OutputStream and write a 6? > > I try that but it didn't work. > > Any suggestion? > > Thanks > > > On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < > florianmanschwetus at gmx.de> wrote: > >> Agustin Mu?oz schrieb: >> >> Hi, I'm still learning about serial communication and I have some doubts. >>> I've got this question about how to do the following thing in rxtx. >>> I have this hardware that connect to a PC using a serial port. These >>> hardware receives data from a telephone line, proccess it, and then send it >>> forward to the serial port. I've used a program named wincomm that shows >>> what information is send it through the serial port and I have the nex >>> behaviour: >>> >>> The hardware has a buffer where all data is stored, that cannot be sent >>> it through the seria port. >>> The program reads the first data send it by the hardware, and keep >>> reading the same data always. >>> There is a button in the application that says enable Ack, and when I >>> click, then the hardware start to send all the stored information, and all >>> the information is shown. >>> >>> I write a class, using rxtx that reads the serial port, and the same >>> thing happens, it remains reading the same (first) data all the time. And I >>> thing something like the enable Ack I'm missing. >>> How can I do this enable Ack from my java code using rxtx? >>> >> Afaik, a look at man ascii reveals: >> Okt Dez Hex Char >> 006 6 06 ACK >> So, i hope this will do the job: >> send(6); >> >> florian >> >>> >>> Thanks in advance >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/b918ab3d/attachment-0029.html From florianmanschwetus at gmx.de Sat Aug 9 00:45:43 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Sat, 09 Aug 2008 08:45:43 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4899667C.6010706@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> Message-ID: <489D3D17.9090209@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >> Florian Manschwetus wrote: >>> Ok, sounds fine for the receiving problem. >>> But why i have to wait after each byte when sending a command squence? >>> (the for loop in send command) >> >> Hi Florian, >> I'd imagine you probably don't! You could send all bytes in one go and >> RXTX would send them. The problem is most probably the other end: >> perhaps it has a really small buffer, some non-standard UART, or a >> crazy timing issue. If you attach a terminal to your output and send >> all the bytes of a command in one go they should appear no problem. >> >> Regards, >> Michael Erskine. >> > correct with a terminal on the other end it works, my idea was that this > basic baud has some influence. Could some one explain what it is for? > > Florian To make it more clear, my problem is that i can't use: outputStream.write(byte[]); => Beamer doesn't understand the sequence. (mostly no answer when he answers then *001) when i use this construct instead: for (int i = 0; i < command.length; i++) { this.outputStream.write(command[i]); try { Thread.sleep(25); } catch (InterruptedException e) { // TODO Auto-generated catch block e.printStackTrace(); } } it works nearly reliable. So what could it be? This Basic Baud is what exactly? Florian -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080809/692304ee/attachment-0029.bin From tjarvi at qbang.org Sat Aug 9 16:37:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Aug 2008 16:37:19 -0600 (MDT) Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489D3D17.9090209@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> <489D3D17.9090209@gmx.de> Message-ID: On Sat, 9 Aug 2008, Florian Manschwetus wrote: > Florian Manschwetus schrieb: >> Michael Erskine schrieb: >>> Florian Manschwetus wrote: >>>> Ok, sounds fine for the receiving problem. >>>> But why i have to wait after each byte when sending a command squence? >>>> (the for loop in send command) >>> >>> Hi Florian, >>> I'd imagine you probably don't! You could send all bytes in one go and >>> RXTX would send them. The problem is most probably the other end: perhaps >>> it has a really small buffer, some non-standard UART, or a crazy timing >>> issue. If you attach a terminal to your output and send all the bytes of a >>> command in one go they should appear no problem. >>> >>> Regards, >>> Michael Erskine. >>> >> correct with a terminal on the other end it works, my idea was that this >> basic baud has some influence. Could some one explain what it is for? >> >> Florian > To make it more clear, > my problem is that i can't use: > outputStream.write(byte[]); > => Beamer doesn't understand the sequence. (mostly no answer when he answers > then *001) > > when i use this construct instead: > > for (int i = 0; i < command.length; i++) { > this.outputStream.write(command[i]); > try { > Thread.sleep(25); > } catch (InterruptedException e) { > // TODO Auto-generated catch block > e.printStackTrace(); > } > } > > it works nearly reliable. > > So what could it be? This Basic Baud is what exactly? > I suspect you are using the 'moon protocol' and don't know it. RXTX enables this by default. The buffer on the other end is first in first out while reading. If the buffer is full, the bits are hand carried to the moon and burried. Then if the other side reads a couple bytes, two more bytes go into the buffer followed by more moon protocol. The resulting array of bytes the other side reads may appear to be scrambled until you go to the moon, get the bits and insert them in the right place. Flow control can prevent the default moon protocol and throttles the communiation by almost writing a byte at a time as need be. Hardware flow control is preferable but software flow control should also work. Read and write can appear to hang if the other side is not connected. This is why we don't enable them all the time. If you can't use flow control, you have to take care with the moon protocol and give the other side time to read. That is what your slower version of write is doing. -- Trent Jarvi tjarvi at qbang.org From rxtx at allenjb.me.uk Mon Aug 11 08:06:36 2008 From: rxtx at allenjb.me.uk (AllenJB) Date: Mon, 11 Aug 2008 15:06:36 +0100 Subject: [Rxtx] Disabling EV_RXFLAG Message-ID: <48A0476C.2090800@allenjb.me.uk> Hi all, I'm working with a device which does not use an EvtChar and need to disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an event mask of FD 01 00 00. The reference software I have uses FB 00 00 00. With the rxtx mask I get framing errors which I believe are caused when the EvtChar is received. Is there currently a way with rxtx (I've using rxtx from Java) to disable EV_RXFLAG? If not from Java, where would I start if I wanted to turn the EV_RXFLAG option off in the C code? I've had a grep of the rxtx source code, but I can't see where EV_RXFLAG is being set. Thanks in advance, AllenJB From tjarvi at qbang.org Mon Aug 11 14:17:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Aug 2008 14:17:27 -0600 (MDT) Subject: [Rxtx] Disabling EV_RXFLAG In-Reply-To: <48A0476C.2090800@allenjb.me.uk> References: <48A0476C.2090800@allenjb.me.uk> Message-ID: On Mon, 11 Aug 2008, AllenJB wrote: > Hi all, > > I'm working with a device which does not use an EvtChar and need to > disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an > event mask of FD 01 00 00. The reference software I have uses FB 00 00 > 00. With the rxtx mask I get framing errors which I believe are caused > when the EvtChar is received. > > Is there currently a way with rxtx (I've using rxtx from Java) to > disable EV_RXFLAG? > > If not from Java, where would I start if I wanted to turn the EV_RXFLAG > option off in the C code? I've had a grep of the rxtx source code, but I > can't see where EV_RXFLAG is being set. > > Thanks in advance, > > AllenJB Hi Allen, I'd look at termios.c::tcsetattr() and termios.c::FillDCB() -- Trent Jarvi tjarvi at qbang.org From superdadusa at gmail.com Tue Aug 12 13:57:32 2008 From: superdadusa at gmail.com (John Choi) Date: Tue, 12 Aug 2008 13:57:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. Message-ID: Hi all, Just let you all know I just start to learn Java. I have download the serial comm package and the source code from open source communities.. I was able to verify with the given message string via serial monitor. when the given message string sends to the serial port then the character return added to the end of string by default if I use "Hello World" however if I changed to something else other than "Hello, World" there is no character return add to the end of string. I thing the library download from rxtx.org has implemented for the special strings. I can do like "login\n" in the string message to make character return but I don't want to add this individual custom character for each command return in every static message string I send, Can any who have done this might help me? Basically, something like this,, Write and add function to the program write a command, Reads the respond from a serial device.. Function handles multiple messages, Write: "com open" Read: Welcome to my world" expected Write: "admin" Read: Password?, expected Write: "admin" Read: you are successfully login terminal, expected. And I need to add a separate function handler handles a character return add to the each command above. If anyone can help this I can do the reset? Thank you in advance, John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0025.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SerialIO.java Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0025.pl From Steffen.DETTMER at ingenico.com Wed Aug 13 02:16:38 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 13 Aug 2008 10:16:38 +0200 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: References: Message-ID: <20080813081638.GA25412@elberon.bln.de.ingenico.com> * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > I can do like "login\n" in the string message to make character > return but I don't want to add this individual custom character > for each command return in every static message string I send, and why not?! > Can any who have done this might help me? what's about with writing a small wrapper function adding the carriage return? However, this would be slow, because either you call write two times (very bad) or the string needs to be copied, \n appended and written (since you are using Java Performance probably isn't so critical). Personally I would write `"login\n"' and `username + "\n"' etc., because since it is part of the command it should be part of the command definition string. > Basically, something like this,, Write and add function to the program write > a command, Reads the respond from a serial device.. correctly reading a `line' is more difficult. If you cannot make assumptions about timeouts and/or you need to have low delay, you need to read byte wise. If you need to save CPU resources you might need to add some buffering layer that you can read byte-wise but that is reading blockwise with some small timeout (lets say for serial lines something around byte transmission time times three or so). > /* > * To change this template, choose Tools | Templates > * and open the template in the editor. > */ :) > package joliba; > > /** > * > * @author root > */ :) > // derived from SUN's examples in the javax.comm package > import java.io.*; > import java.util.*; > //import javax.comm.*; // for SUN's serial/parallel port libraries > import gnu.io.*; // for rxtxSerial library > > public class SerialIO implements Runnable, SerialPortEventListener { > static CommPortIdentifier portId; > static CommPortIdentifier saveportId; > static Enumeration portList; > InputStream inputStream; > SerialPort serialPort; > Thread readThread; You need a thread for your synchronous RPC-style protocol? > static String messageString = "Hello, world!"; > static OutputStream outputStream; > static boolean outputBufferEmptyFlag = false; > > public static void main(String[] args) { > boolean portFound = false; > String defaultPort; > > // determine the name of the serial port on several operating systems > String osname = System.getProperty("os.name","").toLowerCase(); > if ( osname.startsWith("windows") ) { > // windows > defaultPort = "COM1"; > } else if (osname.startsWith("linux")) { > // linux > defaultPort = "/dev/ttyS0"; > } else if ( osname.startsWith("mac") ) { > // mac > defaultPort = "????"; > } else { > System.out.println("Sorry, your operating system is not supported"); > return; > } Is such a construction recommended? Isn't there some abstraction (like COM1 working on any platform)? [...] > try { > // activate the OUTPUT_BUFFER_EMPTY notifier > serialPort.notifyOnOutputEmpty(true); > } catch (Exception e) { > System.out.println("Error setting event notification"); > System.out.println(e.toString()); > System.exit(-1); > } I doubt that -1 is defined, probably some 127 or so would be the result, maybe better simply `throw e'? > public void writetoport() { > System.out.println("Writing \""+messageString+"\" to "+serialPort.getName()); > try { > // write string to serial port > outputStream.write(messageString.getBytes()); > } catch (IOException e) {} > } maybe something like /** * Writes the given output string and an additional carriage * return to the current outputStream. */ public void writeStringToPort( /** The output string (without CR). */ String output ) throws IOException { String outputLine = output + "\n"; outputStream.write(outputLine.getBytes()); } ? > > public SerialIO() { > // initalize serial port > try { > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > } catch (PortInUseException e) {} if the port is in use, you continue? Wonder that this works in Java, I would assume serialPort beeing uninitialized which AFAIK is an error in Java. > try { > inputStream = serialPort.getInputStream(); > } catch (IOException e) {} > > try { > serialPort.addEventListener(this); > } catch (TooManyListenersException e) {} > > // activate the DATA_AVAILABLE notifier > serialPort.notifyOnDataAvailable(true); > > try { > // set port parameters > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > } catch (UnsupportedCommOperationException e) {} > > // start the read thread > readThread = new Thread(this); > readThread.start(); > > } I think in all those exception cases you can abort, because it is unlikely that ignoring those errors allow a successful continuation, so in this case maybe it would be better to add a throw clause to the method. > public void run() { > // first thing in the thread, we initialize the write operation > initwritetoport(); > try { > while (true) { > // write string to port, the serialEvent will read it > writetoport(); > Thread.sleep(1000); > } > } catch (InterruptedException e) {} > } Does this make sense? Your `SimpleReadApp' writes one and the same string each second? > public void serialEvent(SerialPortEvent event) { > switch (event.getEventType()) { > case SerialPortEvent.BI: > case SerialPortEvent.OE: > case SerialPortEvent.FE: > case SerialPortEvent.PE: > case SerialPortEvent.CD: > case SerialPortEvent.CTS: > case SerialPortEvent.DSR: > case SerialPortEvent.RI: > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > break; > case SerialPortEvent.DATA_AVAILABLE: > // we get here if data has been received > byte[] readBuffer = new byte[20]; > try { > // read data > while (inputStream.available() > 0) { > int numBytes = inputStream.read(readBuffer); > } > // print data > String result = new String(readBuffer); > System.out.println("Read: "+result); > } catch (IOException e) {} I doubt that this is correct. I would assume you will get a 20 bytes result always, if more bytes would be available they would be printed in a second line but if less bytes are read I'd assume that the buffer/result contains zero bytes from implicite readBuffer contents initialisation (zero is no string terminator in Java AFAIK). > break; > } > } > } oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From florianmanschwetus at gmx.de Wed Aug 13 06:09:31 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 13 Aug 2008 14:09:31 +0200 Subject: [Rxtx] someone has seen such errors? Message-ID: <48A2CEFB.90007@gmx.de> I mean my communication mostly works, but it is far from perfect could this be the reason? Florian Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/949b9947/attachment-0025.bin From superdadusa at gmail.com Wed Aug 13 08:40:32 2008 From: superdadusa at gmail.com (John Choi) Date: Wed, 13 Aug 2008 08:40:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: <20080813081638.GA25412@elberon.bln.de.ingenico.com> References: <20080813081638.GA25412@elberon.bln.de.ingenico.com> Message-ID: Thank you so much Steffen and I will try that suggestion. John On 8/13/08, Steffen DETTMER wrote: > > * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > > I can do like "login\n" in the string message to make character > > return but I don't want to add this individual custom character > > for each command return in every static message string I send, > > and why not?! > > > Can any who have done this might help me? > > what's about with writing a small wrapper function adding the > carriage return? > However, this would be slow, because either you call write two > times (very bad) or the string needs to be copied, \n appended > and written (since you are using Java Performance probably isn't > so critical). > > Personally I would write `"login\n"' and `username + "\n"' etc., > because since it is part of the command it should be part of the > command definition string. > > > Basically, something like this,, Write and add function to the program > write > > a command, Reads the respond from a serial device.. > > correctly reading a `line' is more difficult. If you cannot make > assumptions about timeouts and/or you need to have low delay, you > need to read byte wise. If you need to save CPU resources you > might need to add some buffering layer that you can read > byte-wise but that is reading blockwise with some small timeout > (lets say for serial lines something around byte transmission > time times three or so). > > > /* > > * To change this template, choose Tools | Templates > > * and open the template in the editor. > > */ > > :) > > > package joliba; > > > > /** > > * > > * @author root > > */ > > :) > > > // derived from SUN's examples in the javax.comm package > > import java.io.*; > > import java.util.*; > > //import javax.comm.*; // for SUN's serial/parallel port libraries > > import gnu.io.*; // for rxtxSerial library > > > > public class SerialIO implements Runnable, SerialPortEventListener { > > static CommPortIdentifier portId; > > static CommPortIdentifier saveportId; > > static Enumeration portList; > > InputStream inputStream; > > SerialPort serialPort; > > Thread readThread; > > You need a thread for your synchronous RPC-style protocol? > > > static String messageString = "Hello, world!"; > > static OutputStream outputStream; > > static boolean outputBufferEmptyFlag = false; > > > > public static void main(String[] args) { > > boolean portFound = false; > > String defaultPort; > > > > // determine the name of the serial port on several operating > systems > > String osname = System.getProperty("os.name","").toLowerCase(); > > if ( osname.startsWith("windows") ) { > > // windows > > defaultPort = "COM1"; > > } else if (osname.startsWith("linux")) { > > // linux > > defaultPort = "/dev/ttyS0"; > > } else if ( osname.startsWith("mac") ) { > > // mac > > defaultPort = "????"; > > } else { > > System.out.println("Sorry, your operating system is not > supported"); > > return; > > } > > Is such a construction recommended? Isn't there some abstraction > (like COM1 working on any platform)? > > [...] > > try { > > // activate the OUTPUT_BUFFER_EMPTY notifier > > serialPort.notifyOnOutputEmpty(true); > > } catch (Exception e) { > > System.out.println("Error setting event notification"); > > System.out.println(e.toString()); > > System.exit(-1); > > } > > I doubt that -1 is defined, probably some 127 or so would be the > result, maybe better simply `throw e'? > > > public void writetoport() { > > System.out.println("Writing \""+messageString+"\" to > "+serialPort.getName()); > > try { > > // write string to serial port > > outputStream.write(messageString.getBytes()); > > } catch (IOException e) {} > > } > > maybe something like > > /** > * Writes the given output string and an additional carriage > * return to the current outputStream. > */ > public void > writeStringToPort( > /** The output string (without CR). */ > String output > ) throws IOException > { > String outputLine = output + "\n"; > outputStream.write(outputLine.getBytes()); > } > > ? > > > > > public SerialIO() { > > // initalize serial port > > try { > > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > > } catch (PortInUseException e) {} > > if the port is in use, you continue? Wonder that this works in > Java, I would assume serialPort beeing uninitialized which AFAIK > is an error in Java. > > > try { > > inputStream = serialPort.getInputStream(); > > } catch (IOException e) {} > > > > try { > > serialPort.addEventListener(this); > > } catch (TooManyListenersException e) {} > > > > // activate the DATA_AVAILABLE notifier > > serialPort.notifyOnDataAvailable(true); > > > > try { > > // set port parameters > > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > } catch (UnsupportedCommOperationException e) {} > > > > // start the read thread > > readThread = new Thread(this); > > readThread.start(); > > > > } > > I think in all those exception cases you can abort, because it is > unlikely that ignoring those errors allow a successful > continuation, so in this case maybe it would be better to add a > throw clause to the method. > > > public void run() { > > // first thing in the thread, we initialize the write operation > > initwritetoport(); > > try { > > while (true) { > > // write string to port, the serialEvent will read it > > writetoport(); > > Thread.sleep(1000); > > } > > } catch (InterruptedException e) {} > > } > > Does this make sense? Your `SimpleReadApp' writes one and the > same string each second? > > > public void serialEvent(SerialPortEvent event) { > > switch (event.getEventType()) { > > case SerialPortEvent.BI: > > case SerialPortEvent.OE: > > case SerialPortEvent.FE: > > case SerialPortEvent.PE: > > case SerialPortEvent.CD: > > case SerialPortEvent.CTS: > > case SerialPortEvent.DSR: > > case SerialPortEvent.RI: > > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > > break; > > case SerialPortEvent.DATA_AVAILABLE: > > // we get here if data has been received > > byte[] readBuffer = new byte[20]; > > try { > > // read data > > while (inputStream.available() > 0) { > > int numBytes = inputStream.read(readBuffer); > > } > > // print data > > String result = new String(readBuffer); > > System.out.println("Read: "+result); > > } catch (IOException e) {} > > I doubt that this is correct. I would assume you will get a 20 > bytes result always, if more bytes would be available they would > be printed in a second line but if less bytes are read I'd assume > that the buffer/result contains zero bytes from implicite > readBuffer contents initialisation (zero is no string terminator > in Java AFAIK). > > > break; > > } > > } > > } > > oki, > > Steffen > > About Ingenico Throughout the world businesses rely on Ingenico for secure > and expedient electronic transaction acceptance. Ingenico products leverage > proven technology, established standards and unparalleled ergonomics to > provide optimal reliability, versatility and usability. This comprehensive > range of products is complemented by a global array of services and > partnerships, enabling businesses in a number of vertical sectors to accept > transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged > information. If you are not the addressee or authorized to receive this for > the addressee, you must not use, copy, disclose or take any action based on > this message or any information herein. If you have received this message in > error, please advise the sender immediately by reply e-mail and delete this > message. Thank you for your cooperation. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/73c4135c/attachment-0024.html From ajmas at sympatico.ca Sat Aug 16 07:15:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 09:15:41 -0400 Subject: [Rxtx] someone has seen such errors? In-Reply-To: <48A2CEFB.90007@gmx.de> References: <48A2CEFB.90007@gmx.de> Message-ID: <43B5E8DA-1D93-4D90-809B-AAF35FF724C5@sympatico.ca> On 13-Aug-08, at 08:09 , Florian Manschwetus wrote: > I mean my communication mostly works, but it is far from perfect > could this be the reason? > > Florian > > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control Judging by the error messages this looks related to the driver you are using. Do a search for the following string with you favourite search engine, it should turn up a few hits: ftdi_set_termios FAILED to set databits/stopbits/parity Andre From ajmas at sympatico.ca Sat Aug 16 19:12:04 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 21:12:04 -0400 Subject: [Rxtx] Using SerialPortEvent? Message-ID: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Hi, Could someone tell me how I should be using the SerialPortEvent? Am I meant to be waiting for data and then simply reading from the inputstream? If this is the case why no just block on an inputstream read? Andr? From tjarvi at qbang.org Sat Aug 16 19:41:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 16 Aug 2008 19:41:13 -0600 (MDT) Subject: [Rxtx] Using SerialPortEvent? In-Reply-To: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> References: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Message-ID: On Sat, 16 Aug 2008, Andre-John Mas wrote: > Hi, > > Could someone tell me how I should be using the SerialPortEvent? Am I > meant to be waiting for data and then simply reading from the > inputstream? If this is the case why no just block on an inputstream > read? > Polling for data is fine also. It really depends upon what you are trying to do. For instance, if you require x bytes before reading, you can start polling after data is available. If you read on the same thread as your GUI and are waiting for data in a read, the results may be less than desirable. Java programming is 'usually' event driven rather than polling based. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sat Aug 16 20:10:39 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 22:10:39 -0400 Subject: [Rxtx] Using SerialPortEvent? In-Reply-To: References: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Message-ID: <3E495D4C-BB28-4845-A6AB-984C9A826BDF@sympatico.ca> On 16-Aug-08, at 21:41 , Trent Jarvi wrote: > On Sat, 16 Aug 2008, Andre-John Mas wrote: > >> Hi, >> >> Could someone tell me how I should be using the SerialPortEvent? Am I >> meant to be waiting for data and then simply reading from the >> inputstream? If this is the case why no just block on an inputstream >> read? >> > > Polling for data is fine also. It really depends upon what you are > trying to do. For instance, if you require x bytes before reading, > you can start polling after data is available. If you read on the > same thread as your GUI and are waiting for data in a read, the > results may be less than desirable. > > Java programming is 'usually' event driven rather than polling based. Sounds good. I thought I would use this opportunity to provide a event based version of the TwoWaySerialComm example. Could you just validate it before I add it to the Wiki: package ajmas74.experimental; import gnu.io.CommPort; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; import gnu.io.SerialPortEvent; import gnu.io.SerialPortEventListener; import java.io.IOException; import java.io.InputStream; import java.io.OutputStream; /** * This version of the TwoWaySerialComm example makes use of the * SerialPortEventListener to avoid polling. * * @author ajmas * */ public class TwoWaySerialComm { public TwoWaySerialComm() { super(); } void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { CommPort commPort = portIdentifier.open(this.getClass().getName(),2000); if ( commPort instanceof SerialPort ) { SerialPort serialPort = (SerialPort) commPort; serialPort .setSerialPortParams (57600 ,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); (new Thread(new SerialWriter(out))).start(); serialPort.addEventListener(new SerialReader(in)); } else { System.out.println("Error: Only serial ports are handled by this example."); } } } /** * Handles the input coming from the serial port. A new line character * is treated as the end of a block in this example. */ public static class SerialReader implements SerialPortEventListener { private InputStream in; private byte[] buffer = new byte[1024]; public SerialReader ( InputStream in ) { this.in = in; } public void serialEvent(SerialPortEvent arg0) { int data; try { int len = 0; while ( ( data = in.read()) > -1 ) { if ( data != '\n' ) { break; } buffer[len++] = (byte) data; } System.out.print(new String(buffer,0,len)); } catch ( IOException e ) { e.printStackTrace(); System.exit(-1); } } } /** */ public static class SerialWriter implements Runnable { OutputStream out; public SerialWriter ( OutputStream out ) { this.out = out; } public void run () { try { int c = 0; while ( ( c = System.in.read()) > -1 ) { this.out.write(c); } } catch ( IOException e ) { e.printStackTrace(); System.exit(-1); } } } public static void main ( String[] args ) { try { (new TwoWaySerialComm()).connect("COM3"); } catch ( Exception e ) { e.printStackTrace(); } } } From lfarkas at lfarkas.org Tue Aug 19 07:32:59 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Tue, 19 Aug 2008 15:32:59 +0200 Subject: [Rxtx] JNI or CNI Message-ID: <48AACB8B.9060606@lfarkas.org> hi, what is the current recommended way to rxtx on linux JNI or it's better to use CNI? is the CNI version fully functional and the same level as the JNI? i currently try to make a rhel/centos/fedora rpm for rxtx but has many problems with the standard dir structure. yours. -- Levente "Si vis pacem para bellum!" From lfarkas at lfarkas.org Tue Aug 19 08:47:34 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Tue, 19 Aug 2008 16:47:34 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel Message-ID: <48AADD06.7040809@lfarkas.org> hi, newer or not so newer linux kernel do not contain the UTS_RELEASE so the current rxtx is not compile on the latest kernels. even if it's commented out in the cvs configure there are other places. i attcahed a patch which fix it (or at least doesn't cause error at non-debug build). ps. is there any plan to the new 2.1-8 release in the near future? there are many changes (at least the license change in all file and in this case create a diff is very difficult)? the latest release more then 2 years old:-( -- Levente "Si vis pacem para bellum!" -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-2.1-uts.patch Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080819/ab5d38ac/attachment-0018.pl From ajmas at sympatico.ca Tue Aug 19 16:21:53 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 19 Aug 2008 18:21:53 -0400 Subject: [Rxtx] Event based example Message-ID: <24735BFB-B088-4B84-8173-FE98DF63B12F@sympatico.ca> Hi, I have just posted an example of using SerialPortEventListener in the Wiki: http://rxtx.qbang.org/wiki/index.php/Event_Based_Two_Way_Communication If you see any issues please could you let me know, or makes the changes. Andre From Martin.Oberhuber at windriver.com Fri Aug 22 04:02:24 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 22 Aug 2008 12:02:24 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <48AADD06.7040809@lfarkas.org> References: <48AADD06.7040809@lfarkas.org> Message-ID: <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> Farkas, there are indeed efforts to get a new RXTX release out the door. Your experience as a package maintainer would likely be helpful during these efforts, since I'd think it makes sense to keep the patches minimal that you must make to have the source compile in your environment. What are the things that you find problematic, apart from the UTS thing that you have mentioned before? What is the timing that you have in mind for your package? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Farkas Levente > Sent: Tuesday, August 19, 2008 4:48 PM > To: rxtx at qbang.org > Subject: [Rxtx] UTS_RELEASE not defined in newer kernel > > hi, > newer or not so newer linux kernel do not contain the > UTS_RELEASE so the > current rxtx is not compile on the latest kernels. even if it's > commented out in the cvs configure there are other places. > i attcahed a patch which fix it (or at least doesn't cause error at > non-debug build). > > ps. is there any plan to the new 2.1-8 release in the near > future? there > are many changes (at least the license change in all file and in this > case create a diff is very difficult)? the latest release more then 2 > years old:-( > > -- > Levente "Si vis pacem para bellum!" > From lfarkas at lfarkas.org Fri Aug 22 04:36:26 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Fri, 22 Aug 2008 12:36:26 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> References: <48AADD06.7040809@lfarkas.org> <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> Message-ID: <48AE96AA.6090505@lfarkas.org> hi, the packages already build for fedora-9 and centos-5 and here: http://www.lfarkas.org/linux/packages/ what i've to patch, the UTS, the configure script, but it's already fixed in the cvs (in another way) and the loadlibrary. the reasons for last one can be found here: https://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_files_that_use_JNI after we test it i'd like to add these packages to fedora and epel main repository (that's why it's be useful a new release after 2 years:-) imho versions are cheap and why not just release 2.1-8? the real code changes are minimal and if something critical bug found still can release 2.1-9:-) ps. and would be better to use simple number for version like 2.1-7 rather then 2.1-7v2. Oberhuber, Martin wrote: > Farkas, > > there are indeed efforts to get a new RXTX release out the > door. Your experience as a package maintainer would likely > be helpful during these efforts, since I'd think it makes > sense to keep the patches minimal that you must make to > have the source compile in your environment. > > What are the things that you find problematic, apart from > the UTS thing that you have mentioned before? > > What is the timing that you have in mind for your package? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >> On Behalf Of Farkas Levente >> Sent: Tuesday, August 19, 2008 4:48 PM >> To: rxtx at qbang.org >> Subject: [Rxtx] UTS_RELEASE not defined in newer kernel >> >> hi, >> newer or not so newer linux kernel do not contain the >> UTS_RELEASE so the >> current rxtx is not compile on the latest kernels. even if it's >> commented out in the cvs configure there are other places. >> i attcahed a patch which fix it (or at least doesn't cause error at >> non-debug build). >> >> ps. is there any plan to the new 2.1-8 release in the near >> future? there >> are many changes (at least the license change in all file and in this >> case create a diff is very difficult)? the latest release more then 2 >> years old:-( >> >> -- >> Levente "Si vis pacem para bellum!" >> -- Levente "Si vis pacem para bellum!" From tjarvi at qbang.org Fri Aug 22 18:50:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Aug 2008 18:50:32 -0600 (MDT) Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <48AE96AA.6090505@lfarkas.org> References: <48AADD06.7040809@lfarkas.org> <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> <48AE96AA.6090505@lfarkas.org> Message-ID: Hi Farkas, The v2 was simply the second build - no code changes. We are comming out with a new release shortly. I would encourage working with distros as you are. The building of rxtx turns out to be a bottle neck in quick releases. We do want stable releases that work for a year or more but I would have no problems with quicker cycles on developing work. I would have no problem working with someone that did builds that receive less testing more often but they do have to come out for multiple platforms from this end. Thanks for the links. On Fri, 22 Aug 2008, Farkas Levente wrote: > hi, > the packages already build for fedora-9 and centos-5 and here: > http://www.lfarkas.org/linux/packages/ > what i've to patch, the UTS, the configure script, but it's already > fixed in the cvs (in another way) and the loadlibrary. the reasons for > last one can be found here: > https://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_files_that_use_JNI > after we test it i'd like to add these packages to fedora and epel main > repository (that's why it's be useful a new release after 2 years:-) > imho versions are cheap and why not just release 2.1-8? the real code > changes are minimal and if something critical bug found still can > release 2.1-9:-) > > ps. and would be better to use simple number for version like 2.1-7 > rather then 2.1-7v2. > > Oberhuber, Martin wrote: >> Farkas, >> >> there are indeed efforts to get a new RXTX release out the >> door. Your experience as a package maintainer would likely >> be helpful during these efforts, since I'd think it makes >> sense to keep the patches minimal that you must make to >> have the source compile in your environment. >> >> What are the things that you find problematic, apart from >> the UTS thing that you have mentioned before? >> >> What is the timing that you have in mind for your package? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >>> On Behalf Of Farkas Levente >>> Sent: Tuesday, August 19, 2008 4:48 PM >>> To: rxtx at qbang.org >>> Subject: [Rxtx] UTS_RELEASE not defined in newer kernel >>> >>> hi, >>> newer or not so newer linux kernel do not contain the >>> UTS_RELEASE so the >>> current rxtx is not compile on the latest kernels. even if it's >>> commented out in the cvs configure there are other places. >>> i attcahed a patch which fix it (or at least doesn't cause error at >>> non-debug build). >>> >>> ps. is there any plan to the new 2.1-8 release in the near >>> future? there >>> are many changes (at least the license change in all file and in this >>> case create a diff is very difficult)? the latest release more then 2 >>> years old:-( >>> >>> -- >>> Levente "Si vis pacem para bellum!" >>> > > > From andy at triera.net Sat Aug 23 15:17:44 2008 From: andy at triera.net (Andy Rozman) Date: Sat, 23 Aug 2008 21:17:44 +0000 Subject: [Rxtx] port not identified on FreeBSD In-Reply-To: References: Message-ID: <48B07E78.2030306@triera.net> Hi ! I have one small problem... I have started using FreeBSD in last few days and I have come accross a problem with rxtx on FreeBSD. I am using usb-to-serial converter, which is identified under FreeBSD without problem as ucom0, and creates link under /dev called ttyU0, which is correct way to be done under FreeBSD (if device would be unidentified it would be called ugen0 - as usb generic). Problem is that I say to rxtx to get my all serial ports this one is not among them. Which names are permissable under linux-like implementations? Which will be accepted as serial ports? Andy From tjarvi at qbang.org Sat Aug 23 13:57:45 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 23 Aug 2008 13:57:45 -0600 (MDT) Subject: [Rxtx] port not identified on FreeBSD In-Reply-To: <48B07E78.2030306@triera.net> References: <48B07E78.2030306@triera.net> Message-ID: On Sat, 23 Aug 2008, Andy Rozman wrote: > Hi ! > > I have one small problem... I have started using FreeBSD in last few > days and I have come accross a problem with rxtx on FreeBSD. > > I am using usb-to-serial converter, which is identified under FreeBSD > without problem as ucom0, and creates link under /dev called > ttyU0, which is correct way to be done under FreeBSD (if device would be > unidentified it would be called ugen0 - as usb generic). Problem is that > I say to rxtx to get my all serial ports this one is not among them. > Which names are permissable under linux-like implementations? Which will > be accepted as serial ports? > > Andy > Thanks Andy! We will add ttyU* to FreeBSD. For now you can use properties to enable the port. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting#How_does_rxtx_detect_ports.3F__Can_I_override_it.3F The fix: diff -u -r1.16.2.59 RXTXCommDriver.java --- RXTXCommDriver.java 18 Nov 2007 22:32:41 -0000 1.16.2.59 +++ RXTXCommDriver.java 23 Aug 2008 19:55:25 -0000 @@ -644,6 +644,7 @@ { String[] Temp = { "ttyd", //general purpose serial ports + "ttyU", //general purpose USB serial ports "cuaa", //dialout serial ports "ttyA", //Specialix SI/XIO dialin ports "cuaA", //Specialix SI/XIO dialout ports -- Trent Jarvi tjarvi at qbang.org From rick_knight at rlknight.com Mon Aug 4 13:25:10 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Mon, 04 Aug 2008 12:25:10 -0700 Subject: [Rxtx] Sun's Comm API? Message-ID: <48975796.4010600@rlknight.com> I have an application that requires the javax compatible version of RXTX and Sun's comm api. I've been able to download and extract the version of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api anywhere. Can someone tell me where I can find it? Or maybe send me a copy? Also, when I try to build RXTX, configure and make complete successfully but make install failes with this error libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 I've never come accross this error before. How can I get past it? Thanks, Rick From bboyes at systronix.com Mon Aug 4 19:10:01 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:10:01 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48975796.4010600@rlknight.com> References: <48975796.4010600@rlknight.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/cb9c6167/attachment-0034.html From bboyes at systronix.com Mon Aug 4 19:12:37 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:12:37 -0600 Subject: [Rxtx] Towards an RXTX release - CSR BT/USB chipset In-Reply-To: <488FB7E7.8000802@gmail.com> References: <460801A4097E3D4CA04CC64EE648584806C56CF0@ism-mail03.corp.ad.wrs.com> <13557-75390@sneakemail.com> <20980-23424@sneakemail.com> <488FB7E7.8000802@gmail.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/52236088/attachment-0034.html From tjarvi at qbang.org Mon Aug 4 19:42:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 19:42:21 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: On Mon, 4 Aug 2008, Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: > I have an application that requires the javax compatible > version of RXTX > and Sun's comm api. I've been able to download and extract > the version > of RXTX that I need (2.0-7pre2) but I can't find Sun's camm > api > anywhere. Can someone tell me where I can find it? Or maybe > send me a > > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm port > support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have just > a ZIP with only the .class JAR file - no source or docs), has a readme > with these comments: > > This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release.? The 2.0.3 release itself is > no longer distributed.? comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project.? The RxTx project (http://www.rxtx.org ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org) was opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support.? Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins.? Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > ? > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > I hope that is helpful! > It would be nice to work with Sun to resolve those longstanding issues. But it may not be practical unless the process goes as fast and painless as the grandfathering of commapi did. Another option may be the old kaffe extensions that moved to gnu classpathx. These don't have the native libraries but should provide the 2.0 interface and the javax.comm.properties mechansim for SPI. http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Mon Aug 4 20:23:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Mon, 04 Aug 2008 20:23:57 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4897B9BD.5070809@ergotech.com> Has there been any work/would it be possible, to layer a javacomm look-alike on top of the GNU code? The goal is not to move the javax code forward, but to emulate the "legacy" javax packages for people who still need this. Jim Trent Jarvi wrote: > On Mon, 4 Aug 2008, Bruce Boyes wrote: > >> At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible >> version of RXTX >> and Sun's comm api. I've been able to download and extract >> the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm >> api >> anywhere. Can someone tell me where I can find it? Or maybe >> send me a >> >> >> javaxcomm has had a sort of on-again off-again history. The windoze >> version has been languishing for years (literally) but there are newer >> versions for other OS's. >> >> We try to keep links on one of our help pages current: >> http://www.practicalembeddedjava.com/tools/javatools_list.html >> which gets you to here: >> http://java.sun.com/products/javacomm/ >> where it says in fact they no longer even support Windows and Mac: >> "Implementations of the API are currently available for Solaris SPARC, >> Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so >> someone could support it. But I guess that's part of the reason RXTX >> exists! >> >> So one of Sun's own products, SunSPOT, has to use RXTX to get comm port >> support. >> >> The version we use is 2.0 from 11/15/1998. I have posted it on our >> website, which is within the terms of the license agreement contained >> therein (as I understand it). >> >> The last version of javaxcomm for Windows, 2.0.3, (for which I have just >> a ZIP with only the .class JAR file - no source or docs), has a readme >> with these comments: >> >> This distribution contains the comm.jar file original part >> of the COMMAPI 2.0.3 release. The 2.0.3 release itself is >> no longer distributed. comm.jar, which contains the comm >> API java class files (eg. Sun's binary implementation of the >> interface classes), is being made available, unsupported, >> with no obligation to fix bugs, at the request of the RXTX >> project. The RxTx project (http://www.rxtx.org ), uses the >> comm.jar class files, but provides their own native library >> components to provide support for other platforms. >> >> The 2.0.3 comm.jar is being provided in this way because >> as of COMMAPI 3.x, the java binary implementation forked and >> became incompatible with the RxTx project's native code. >> Due to the lack of a clear business case, and to resource >> constraints, no additional resources are being >> provided to provide an alternative engineering solution >> at the time of writing. >> >> RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: >> >> Ultimately the COMMAPI would be better served if a Java >> Community Process JSR (http://www.jcp.org) was opened and >> the COMMAPI was rearchitected to provide a more pluggable >> framework to improve cross-platform support. Such an >> architecture would embody a better defined and better >> documented SPI interface, including a way for comm. ports >> to be revealed to the client application through the API >> via platform-aware plugins. Similarly, native code used >> to access comm port in general could be handled more >> flexibly using a plugin model, whereby on any platform, >> multiple native modules could be in use simultaneously. >> >> Since there are now various ways serial ports can be implemented >> and accessed, modular comm. port JNI native libraries would be >> of benefit insofar as removing the burden of over-generalization >> from any single native component, or inversely, by relieving the >> implicit constraint that comm. drivers be accessed only via a >> monolithic mechanism, such as the UNIX vnode interface. >> >> paul.klissner at sun.com >> 6/10/06 >> >> I hope that is helpful! >> > > It would be nice to work with Sun to resolve those longstanding issues. > But it may not be practical unless the process goes as fast and painless > as the grandfathering of commapi did. > > Another option may be the old kaffe extensions that moved to gnu > classpathx. These don't have the native libraries but should provide > the 2.0 interface and the javax.comm.properties mechansim for SPI. > > http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Mon Aug 4 21:09:15 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 21:09:15 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? Message-ID: Hi Jim, I will not step into the javax.comm namespace without Sun's explicite permission. I fully understand the pain point you are trying to address. In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm Linux) - which remains an integral part of rxtx. At the time it was a win for Sun and rxtx. The Sun commapi license is/was fairly clear that rxtx should not step into that namespace. It made sense as Sun was active in that space and rxtx may go into another namespace - it was an experiment in working with Sun. This may sound silly looking at something that happened almost 10 years ago. In a community of respect which Sun helped create, there is no question about what to do. I hope eventually Sun will step up and do a right thing too. I agree that this is hurting the API more than helping it. There are also questions about how to replace the API in the long term which includes HID support which isn't going well so far. Others that can't even look at Sun's javax.comm today and can look at Kaffe's contribution to classpathx can easily work around such restrictions. On Mon, 4 Aug 2008, Jim Redman wrote: > Has there been any work/would it be possible, to layer a javacomm > look-alike on top of the GNU code? > > The goal is not to move the javax code forward, but to emulate the > "legacy" javax packages for people who still need this. > > Jim > > Trent Jarvi wrote: >> >> It would be nice to work with Sun to resolve those longstanding issues. >> But it may not be practical unless the process goes as fast and painless >> as the grandfathering of commapi did. >> >> Another option may be the old kaffe extensions that moved to gnu >> classpathx. These don't have the native libraries but should provide >> the 2.0 interface and the javax.comm.properties mechansim for SPI. >> >> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From florianmanschwetus at gmx.de Tue Aug 5 05:04:46 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 13:04:46 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: References: <48971C1F.9020806@gmx.de> Message-ID: <489833CE.1040801@gmx.de> Just look at sendCommand in this method I have to place a Thread.sleep(20) after each byte send to get working. Even the event based receive doesn't work fine but this could be may stupidness. The specifikation document (it is on the last pages of the manual) for the beamer could be found on: http://www.optoma.co.uk/support.aspx Florian Manschwetus Trent Jarvi schrieb: > > Hi Florian > > Sorry for the top post in advance. I worry you may not see my answer > under all your code :) > > I have not received this email before. This is 500k of code which I > don't have time to read. I can spend about 5 min on each hobby email > and still get to work in the morning. I have a couple suggestions for > how to get an answer. > > First, cut out your comments and extra code so you can demonstrate the > question (I might even glance and see what is wrong then). Don't go for > a working final product. Isolate the problem using a simple program and > then ask with that as an example. If I did what you just did, I'd have > to post 3/4 of a million lines of code :) > > Second, join the rxtx mail-list and ask there. This will give you 100x > more eyes. I'll also read and try to follow. > > -- > taj > > > > On Mon, 4 Aug 2008, Florian Manschwetus wrote: > >> It could be that my university account is blocked by filters so >> resending from here. >> >> >> Topic is to control Optoma HD80 beamer using rs232 serial chat. >> This code is able to detect power state and switch the beamer on / off. >> connected is the beamer using a digitus usb 2.0 serial adapter with an >> FT232 USB-Serial adapter the systems architecture is amd64. >> >> Please take a look in the sendCommand routine i have to place theire >> those Thread.sleep to get it working. >> Now the question is this correct or is there a better way to get this >> working correctly? >> >> In the javadoc coming with the install i found this: >> setBaudBase >> >> public boolean setBaudBase(int BaudBase) >> throws UnsupportedCommOperationException, >> java.io.IOException >> >> Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 >> before using. >> >> could this explain the error? >> I attached my java source and the protocol description for the beamer >> (available on vendor website). >> >> thx, >> Florian Manschwetus >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: TestRS232.java Type: text/x-java Size: 9143 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0068.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0069.bin From michael.erskine at ketech.com Tue Aug 5 05:53:49 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Tue, 5 Aug 2008 12:53:49 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489833CE.1040801@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> > Just look at sendCommand in this method I have to place a > Thread.sleep(20) after each byte send to get working. Even the event > based receive doesn't work fine but this could be may stupidness. Hi Florian, Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. Regards, Michael Erskine. From florianmanschwetus at gmx.de Tue Aug 5 07:28:15 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:28:15 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> Message-ID: <4898556F.8000208@gmx.de> Michael Erskine schrieb: >> Just look at sendCommand in this method I have to place a >> Thread.sleep(20) after each byte send to get working. Even the event >> based receive doesn't work fine but this could be may stupidness. > > Hi Florian, > > Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. > > Regards, > Michael Erskine. > Ok, sounds fine for the receiving problem. But why i have to wait after each byte when sending a command squence? (the for loop in send command) Florian > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/284f350c/attachment-0033.bin From florianmanschwetus at gmx.de Tue Aug 5 07:44:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:44:14 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <4898592E.2020908@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >>> Just look at sendCommand in this method I have to place a >>> Thread.sleep(20) after each byte send to get working. Even the event >>> based receive doesn't work fine but this could be may stupidness. >> >> Hi Florian, >> >> Yes, naturally you'll have to wait for a response from the other end. >> Why not wait for notification from the event thread perhaps using a >> BlockingDeque rather than your LinkedList. Generally I >> try to decouple all input and output streams: in your case your >> application is operating synchronously like the "expect" program >> (http://expect.nist.gov/) so waits (or timeouts) will need to be >> factored in. >> >> Regards, >> Michael Erskine. >> > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) > > Florian Furthermore there is this basic baud with this confusing javadoc entry: public boolean setBaudBase(int BaudBase) throws UnsupportedCommOperationException, java.io.IOException Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 before using. maybe this could explain something Florian >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/006c7425/attachment-0033.bin From jredman at ergotech.com Tue Aug 5 09:13:36 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 05 Aug 2008 09:13:36 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: Message-ID: <48986E20.3060104@ergotech.com> Trent, So two issues: 1) Technically I'm still not sure how easy/practical a layer would be. The problems are always classes like listeners, and wrapping returns of gnu.io classes. I really see it as a "delegate" type of concept. Any thoughts or ideas of the practicality of this approach? The idea is not to modify RXTX. 2) Javax. The javax namespace does seem to be in widespread use outside of Sun (the same is true for the java namespace). The classpath extensions, or some other location, should be interested in a JavaComm implementation even if it does have dependencies on RXTX. Would you have any philosophical objection to an approach like that? Of course, I suspect it might be better if someone with that authority at Sun would admit that the javax namespace is already in the wild and that there is no problem with it being used within RXTX. Jim Trent Jarvi wrote: > Hi Jim, > > I will not step into the javax.comm namespace without Sun's explicite > permission. I fully understand the pain point you are trying to address. > > In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm > Linux) - which remains an integral part of rxtx. At the time it was a win for > Sun and rxtx. > > The Sun commapi license is/was fairly clear that rxtx should not step into that > namespace. It made sense as Sun was active in that space and rxtx may go into > another namespace - it was an experiment in working with Sun. > > This may sound silly looking at something that happened almost 10 years ago. > In a community of respect which Sun helped create, there is no question about > what to do. I hope eventually Sun will step up and do a right thing too. > > I agree that this is hurting the API more than helping it. There are also > questions about how to replace the API in the long term which includes HID > support which isn't going well so far. > > Others that can't even look at Sun's javax.comm today and can look at Kaffe's > contribution to classpathx can easily work around such restrictions. > > On Mon, 4 Aug 2008, Jim Redman wrote: > >> Has there been any work/would it be possible, to layer a javacomm >> look-alike on top of the GNU code? >> >> The goal is not to move the javax code forward, but to emulate the >> "legacy" javax packages for people who still need this. >> >> Jim >> >> Trent Jarvi wrote: >>> It would be nice to work with Sun to resolve those longstanding issues. >>> But it may not be practical unless the process goes as fast and painless >>> as the grandfathering of commapi did. >>> >>> Another option may be the old kaffe extensions that moved to gnu >>> classpathx. These don't have the native libraries but should provide >>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>> >>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From sandeep at genevasoftech.com Tue Aug 5 11:18:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Tue, 05 Aug 2008 22:48:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <48988B6C.5080409@genevasoftech.com> Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. *-- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/ad20f1cb/attachment-0033.html From Martin.Oberhuber at windriver.com Tue Aug 5 13:30:17 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Tue, 5 Aug 2008 21:30:17 +0200 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Sandeep, shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on Sol7 but I've successfully run it on Sol9 and Sol10. Or is your request really about a native 64bit variant? I'm afraid that then you're out of luck since I think that quite a bit of RXTX is not yet ready for 64 bit. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Sandeep Kumar K Sent: Tuesday, August 05, 2008 7:19 PM To: rxtx at qbang.org Subject: [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so for Solaris 9 Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. -- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/81b7f988/attachment-0033.html From tjarvi at qbang.org Tue Aug 5 22:38:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 22:38:34 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 5 Aug 2008, Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built > on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid that > then > you're out of luck since I think that quite a bit of RXTX is not yet > ready > for 64 bit. > While rxtx-2.1-7 probably has problems, The CVS code should be OK for 64 bit Solaris. If it isn't, let me know and I'll find which patch is missing. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Aug 5 23:13:00 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 23:13:00 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48986E20.3060104@ergotech.com> References: <48986E20.3060104@ergotech.com> Message-ID: On Tue, 5 Aug 2008, Jim Redman wrote: > Trent, > > So two issues: > > 1) Technically I'm still not sure how easy/practical a layer would be. The > problems are always classes like listeners, and wrapping returns of gnu.io > classes. I really see it as a "delegate" type of concept. Any thoughts or > ideas of the practicality of this approach? The idea is not to modify RXTX. I have not put too much thought into this. I assume you want what rxtx 2.0 provided to tie into javax.comm implementations. More classes could be added to rxtx 2.1-7 for SPI support. Maintaining rxtx-2.0 could also be handed to someone if they like. > > 2) Javax. The javax namespace does seem to be in widespread use outside of > Sun (the same is true for the java namespace). The classpath extensions, or > some other location, should be interested in a JavaComm implementation even > if it does have dependencies on RXTX. Would you have any philosophical > objection to an approach like that? > No problems. Classpathx would be a possible place to do it. I'd suggest thinking twice about what this involves in practical terms. You would be wanting to revive the 2.0 API while Sun is at 3.0 and grandfathering the JSR. This undermines the main reason (established api) for using the javax.comm namespace and does not leave such a project in a good position. The only win I see here is maintaining support for applications that can't migrate namespaces. Not that that isn't important. At some point it is going to be less work to just edit the bytecode :) Such a javax.comm effort would also be signing up new projects that decided to use the work up for concerns they probably will not understand or expect. That probably isn't a good path to facilitate for new projects at this time. We will put a good faith effort to work well with others but keep in mind the project has limited bandwidth for such efforts. > Of course, I suspect it might be better if someone with that authority at Sun > would admit that the javax namespace is already in the wild and that there is > no problem with it being used within RXTX. > > Jim > > Trent Jarvi wrote: >> Hi Jim, >> >> I will not step into the javax.comm namespace without Sun's explicite >> permission. I fully understand the pain point you are trying to address. >> >> In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java >> Comm Linux) - which remains an integral part of rxtx. At the time it was a >> win for Sun and rxtx. >> >> The Sun commapi license is/was fairly clear that rxtx should not step into >> that namespace. It made sense as Sun was active in that space and rxtx may >> go into another namespace - it was an experiment in working with Sun. >> >> This may sound silly looking at something that happened almost 10 years >> ago. In a community of respect which Sun helped create, there is no >> question about what to do. I hope eventually Sun will step up and do a >> right thing too. >> >> I agree that this is hurting the API more than helping it. There are also >> questions about how to replace the API in the long term which includes HID >> support which isn't going well so far. >> >> Others that can't even look at Sun's javax.comm today and can look at >> Kaffe's contribution to classpathx can easily work around such >> restrictions. >> >> On Mon, 4 Aug 2008, Jim Redman wrote: >> >>> Has there been any work/would it be possible, to layer a javacomm >>> look-alike on top of the GNU code? >>> >>> The goal is not to move the javax code forward, but to emulate the >>> "legacy" javax packages for people who still need this. >>> >>> Jim >>> >>> Trent Jarvi wrote: >>>> It would be nice to work with Sun to resolve those longstanding issues. >>>> But it may not be practical unless the process goes as fast and painless >>>> as the grandfathering of commapi did. >>>> >>>> Another option may be the old kaffe extensions that moved to gnu >>>> classpathx. These don't have the native libraries but should provide >>>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>>> >>>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From sandeep at genevasoftech.com Wed Aug 6 00:03:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Wed, 06 Aug 2008 11:33:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: <48993EB8.30107@genevasoftech.com> Thank you Mr. Martin for your suggestion. The native file which is given in rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am getting the following error . Any suggestions to solve this issue. I am using Solaris SPARC 64 bit machine. ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) thrown while loading gnu.io.RXTXCommDriver Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(Unknown Source) at java.lang.ClassLoader.loadLibrary(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) at com.ReadFromModem.main(ReadFromModem.java:84) * * *Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid > that then > you're out of luck since I think that quite a bit of RXTX is not yet ready > for 64 bit. > > Cheers, > -- > *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > ------------------------------------------------------------------------ > *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On > Behalf Of *Sandeep Kumar K > *Sent:* Tuesday, August 05, 2008 7:19 PM > *To:* rxtx at qbang.org > *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so > for Solaris 9 > > Hi, > > Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 > bit machine. The librxtxSerial.so given in website is for Solaris 8. > > *-- > > Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/1e920343/attachment-0033.html From tjarvi at qbang.org Wed Aug 6 00:21:42 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 00:21:42 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <48993EB8.30107@genevasoftech.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> <48993EB8.30107@genevasoftech.com> Message-ID: Hi Sandeep You may be out of luck unless you can compile the 2.1 src in CVS (requires gnu make and gcc). But you could try the ToyBox(R)(TM) which is a collection of WiLdLy untested cross compiled 2.1-7 binaries covering everything from the ibm z series to embeded arm/ppc. To give an idea how poorly these are tested, I don't even know if z series machines have a serial port. ftp://www.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Solaris They should at least match the binary types. Actually, I think if you use the rxtx jar from CVS with that file, it should 'work' as the fix for 64 bits was in java not the native code. You could just cd rxtx*/src; javac *.java then jar -cf RXTXcomm.jar `find -name \*.class` to create the hybrid which will complain about version information a bit. On Wed, 6 Aug 2008, Sandeep Kumar K wrote: > Thank you Mr. Martin for your suggestion. The native file which is given in > rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am > getting the following error . > Any suggestions to solve this issue. > I am using Solaris SPARC 64 bit machine. > > ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar > java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 > (Possible cause: architecture word > width mismatch) thrown while loading gnu.io.RXTXCommDriver > Exception in thread "main" java.lang.UnsatisfiedLinkError: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF > class: ELFCLASS64 (Possible cause: > architecture word width mismatch) > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(Unknown Source) > at java.lang.ClassLoader.loadLibrary(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > at com.ReadFromModem.main(ReadFromModem.java:84) > > * > * > > *Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > > > Oberhuber, Martin wrote: >> Sandeep, >> shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse >> variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on >> Sol7 but I've successfully run it on Sol9 and Sol10. >> Or is your request really about a native 64bit variant? I'm afraid that >> then >> you're out of luck since I think that quite a bit of RXTX is not yet ready >> for 64 bit. >> Cheers, >> -- >> *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> ------------------------------------------------------------------------ >> *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On >> Behalf Of *Sandeep Kumar K >> *Sent:* Tuesday, August 05, 2008 7:19 PM >> *To:* rxtx at qbang.org >> *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so >> for Solaris 9 >> >> Hi, >> >> Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 >> bit machine. The librxtxSerial.so given in website is for Solaris 8. >> >> *-- >> Thanks & Regards >> >> Sandeep Kumar K >> Sr. Software Engineer >> Geneva Software Technologies >> Whitefield, Bangalore >> Mob : 9880193454* >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> From michael.erskine at ketech.com Wed Aug 6 01:39:28 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 6 Aug 2008 08:39:28 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Florian Manschwetus wrote: > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) Hi Florian, I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. Regards, Michael Erskine. From florianmanschwetus at gmx.de Wed Aug 6 02:53:16 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 06 Aug 2008 10:53:16 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Message-ID: <4899667C.6010706@gmx.de> Michael Erskine schrieb: > Florian Manschwetus wrote: >> Ok, sounds fine for the receiving problem. >> But why i have to wait after each byte when sending a command squence? >> (the for loop in send command) > > Hi Florian, > I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. > > Regards, > Michael Erskine. > correct with a terminal on the other end it works, my idea was that this basic baud has some influence. Could some one explain what it is for? Florian > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/c2b4fa84/attachment-0033.bin From rick_knight at rlknight.com Wed Aug 6 13:01:07 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:01:07 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F4F3.3020707@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > I have an application (Readerware) that uses RXTX with Javax to access the serial port. This used to work fine under previous Linux' and Java, but something has changed, I assume with Java itself , that is causing the application to fail with a link error. The application is not able to find librxtxSerialParallel.so. RXTX supplies librxtxSerial.so and librxtxParallel.so, but not librxtxSerialParallel.so. Where can I get librxtxSerialParallel.so, or do I need it? Is something else causing the lib to not be found? Thanks, Rick Knight From rick_knight at rlknight.com Wed Aug 6 13:17:55 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:17:55 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F8E3.5060400@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Thanks for the reply. The developer of the app I'm trying to use (Readerware) has sent me a copy of the comm.api and I've copied the library (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar into the proper places. When I try to run the application, I get this error... Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: /usr/lib/libSolarisSerialParallel.so: /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not little-endian (Possible cause: endianness mismatch) Caught java.lang.UnsatisfiedLinkError: com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I while loading driver com.sun.comm.SolarisDriver Is there a way around this error? Thanks again, Rick Knight From jlar310 at gmail.com Wed Aug 6 13:37:42 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 14:37:42 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899F8E3.5060400@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > The developer of the app I'm trying to use (Readerware) has sent me a > copy of the comm.api and I've copied the library > (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar > into the proper places. When I try to run the application, I get this > error... > > Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: > /usr/lib/libSolarisSerialParallel.so: > /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not > little-endian (Possible cause: endianness mismatch) > Caught java.lang.UnsatisfiedLinkError: > com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I > > while loading driver com.sun.comm.SolarisDriver > > Is there a way around this error? What host OS are you running? From your original post it looks like 32 bit Linux. The libSolarisSerialParallel.so file is for Sun Solaris and will vary depending on the underlying hardware architecture as well. Sorry for the double post Rick, but I failed to send this to the list the first time... -- Jeff From rick_knight at rlknight.com Wed Aug 6 13:44:29 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:44:29 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: <4899FF1D.9030504@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > > >> The developer of the app I'm trying to use (Readerware) has sent me a >> copy of the comm.api and I've copied the library >> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >> into the proper places. When I try to run the application, I get this >> error... >> >> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >> /usr/lib/libSolarisSerialParallel.so: >> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >> little-endian (Possible cause: endianness mismatch) >> Caught java.lang.UnsatisfiedLinkError: >> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >> >> while loading driver com.sun.comm.SolarisDriver >> >> Is there a way around this error? >> > > What host OS are you running? From your original post it looks like 32 > bit Linux. > > The libSolarisSerialParallel.so file is for Sun Solaris and will vary > depending on the underlying hardware architecture as well. > > I'm running Kubuntu Linux (debian based). It's 32 bit. Rick Knight From jlar310 at gmail.com Wed Aug 6 15:33:23 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 16:33:23 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > I don't think Sun did binary libraries for Linux in the 2.0 version. Can someone with more historical experience than I confirm that? I recently tried to port a Comm API application from Solaris sparc to Linux x86 and likewise could not get my hands on the binary libraries. I eventually just re-wrote the code to use the gnu namespace packages and rxtx 2.1. What I don't understand is why your application vendor does not provide everything you need to run their software. FYI: I have librxtxParallel.so and librxtxSerial.so installed at JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is /usr/java/default which is actually a softlink to /usr/java/jre1.6.0_05. -- Jeff From defiantlew at yahoo.com.au Wed Aug 6 16:29:33 2008 From: defiantlew at yahoo.com.au (Lew L) Date: Thu, 7 Aug 2008 08:29:33 +1000 Subject: [Rxtx] Sun's Comm API Documentation References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> Message-ID: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> As a matter of interest is the Sun Comm API documentation available somewhere? I have tried the Sun site but it seems to have been removed. Unless I have missed the documentation for RXTX? I javadocced the RXTX source but information (to me) is minimal. Somewhere I got the impression that the Sun Comm API docs is, or was, compatible with RXTX, what is the best docs to use in conjuntion with RXTX and where may the be available? Cheers Lew From rick_knight at rlknight.com Wed Aug 6 17:18:33 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:18:33 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A3149.4050306@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff I'm not sure if I posted this here or not, but when I try to build RXTX from source I get this install error... make all-am make[1]: Entering directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' make[1]: Nothing to be done for `all-am'. make[1]: Leaving directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 Can you tell me how to get past this error and get RXTX built and installed? Thanks, Rick From bboyes at systronix.com Wed Aug 6 17:40:12 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Wed, 06 Aug 2008 17:40:12 -0600 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: At 16:29 08/06/2008, Lew L wrote: >As a matter of interest is the Sun Comm API documentation available >somewhere? I have tried the Sun site but it seems to have been removed. It's in the file we have posted, link in prev email (sorry, in a huge hurry right now). Javadocs definitely there. >Unless I have missed the documentation for RXTX? I javadocced the RXTX >source but information (to me) is minimal. >Somewhere I got the impression that the Sun Comm API docs is, or was, >compatible with RXTX, what is the best docs to use in conjuntion with RXTX >and where may the be available? Yeah, this is one of my concerns/beefs. There is little documentation for RXTX and it isn't just the same as javaxcomm. I would be willing to help out writing docs for RXTX! Yes really... esp if we can fix the Bluetooth issues. best regards Bruce >Cheers >Lew > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx ------- WWW.SYSTRONIX.COM ---------- Real embedded Java and much more +1-801-534-1017 Salt Lake City, USA From rick_knight at rlknight.com Wed Aug 6 17:54:08 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:54:08 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A39A0.2090309@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff, I would like for my vendor to switch to rxtx 2.1. It would make things much easier for me. I'm not sure why he's still using the javax compatible code. He's a small operation. Re-writing the code to use gnu namespace sounds like a major overhaul. Was it? Thanks, Rick From tjarvi at qbang.org Wed Aug 6 21:35:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:35:12 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: >> >>> Jeff wrote: >>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>>> >>>> >>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things > much easier for me. I'm not sure why he's still using the javax > compatible code. He's a small operation. Re-writing the code to use gnu > namespace sounds like a major overhaul. Was it? > Hi Jeff, The changes are fairly mechanical. Imports need to change and any explicite use of the namespace needs to change such as catching an exception. The following script was made for maintaining rxtx 2.0 but can apply to other needs. It is in the contrib dir with rxtx source. #!/bin/sh # Don't use! :) # # Sat, 03 May 2003 16:45:08 Modifications from J?rg Weule # Create a ed-cmd for the change of one pattern # case $1 in gnu) X=g/javax_comm/s+javax_comm+gnu_io+g ;; javax) X=g/gnu_io/s+gnu_io+javax_comm+g ;; *) echo;echo;echo From the top rxtx directory run;echo;echo -e \\t./ChangePackage.sh gnu;echo -e \\t\\tor;echo -e \\t./ChangePackage.sh javax;echo;echo; exit 0 ;; esac # # ed will be used to keep the owner and mode of the files unchanged. # We have run the ed-script for the characters '.' '/' as well. # "tr _ $D" do the change. # find . -type f -a -print | grep -v $0 | (while read F ; do ( echo $X; echo $X| tr _ /; echo $X| tr _ .; echo w; echo q ) | ed $F 2>&1 >/dev/null done ) # # Now we do little changes at the Makefiles. Hope that all we need. # find . -name Makefile\* -a -print | (while read F ; do cat < References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: On Thu, 7 Aug 2008, Lew L wrote: > As a matter of interest is the Sun Comm API documentation available > somewhere? I have tried the Sun site but it seems to have been removed. > > Unless I have missed the documentation for RXTX? I javadocced the RXTX > source but information (to me) is minimal. > Somewhere I got the impression that the Sun Comm API docs is, or was, > compatible with RXTX, what is the best docs to use in conjuntion with RXTX > and where may the be available? > Hi Lew, The documentation on Sun's website is accurate. The changes that are problematic in 3.0 are on the backside which rxtx used to plug into. http://java.sun.com/products/javacomm/reference/api/index.html CommPortIdentifier may have some minor differences (judging by the authors notes). -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Aug 6 21:46:08 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:46:08 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > If javax.comm.properties is properly installed and you are using a 2.0 version of Sun's commapi with rxtx 2.0, you should not see the library attempt to load libSolarisSerialParallel.so. Sun CommAPI 3.0 will not work with any version of rxtx as it is hard coded to use the shared library. See the INSTALL file with rxtx-2.0 source for more help with the properties file. -- Trent Jarvi tjarvi at qbang.org From jlar310 at gmail.com Thu Aug 7 06:32:06 2008 From: jlar310 at gmail.com (Jeff) Date: Thu, 7 Aug 2008 07:32:06 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > Jeff wrote: >> >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >> wrote: >> >>> >>> Jeff wrote: >>> >>>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>> wrote: >>>> >>>> >>>> >>>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things much > easier for me. I'm not sure why he's still using the javax compatible code. > He's a small operation. Re-writing the code to use gnu namespace sounds like > a major overhaul. Was it? I found it quite easy. In fact, in order to accommodate the transition, I actually separated all of the code that deals directly with the Comm API or RXTX into a helper class. The helper class was then coded to use reflection to determine which library was available and then instantiate the necessary objects. No direct imports of either library are used. The main application just needs to get it's hands on the IO streams and need not deal directly with the libraries. Other programs may not be so simple... But this doesn't really help you unless your vendor forks over the source code... -- Jeff From rick_knight at rlknight.com Thu Aug 7 09:47:12 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Thu, 07 Aug 2008 08:47:12 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: <489B1900.10108@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >>> wrote: >>> >>> >>>> Jeff wrote: >>>> >>>> >>>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>>> copy of the comm.api and I've copied the library >>>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>>> into the proper places. When I try to run the application, I get this >>>>>> error... >>>>>> >>>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>>> /usr/lib/libSolarisSerialParallel.so: >>>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>>> little-endian (Possible cause: endianness mismatch) >>>>>> Caught java.lang.UnsatisfiedLinkError: >>>>>> >>>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>>> >>>>>> while loading driver com.sun.comm.SolarisDriver >>>>>> >>>>>> Is there a way around this error? >>>>>> >>>>>> >>>>>> >>>>> What host OS are you running? From your original post it looks like 32 >>>>> bit Linux. >>>>> >>>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>>> depending on the underlying hardware architecture as well. >>>>> >>>>> >>>>> >>>>> >>>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>>> >>>> >>>> >>> I don't think Sun did binary libraries for Linux in the 2.0 version. >>> Can someone with more historical experience than I confirm that? >>> >>> I recently tried to port a Comm API application from Solaris sparc to >>> Linux x86 and likewise could not get my hands on the binary libraries. >>> I eventually just re-wrote the code to use the gnu namespace packages >>> and rxtx 2.1. >>> >>> What I don't understand is why your application vendor does not >>> provide everything you need to run their software. >>> >>> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >>> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >>> /usr/java/default which is actually a softlink to >>> /usr/java/jre1.6.0_05. >>> >>> >>> >> Jeff, >> >> I would like for my vendor to switch to rxtx 2.1. It would make things much >> easier for me. I'm not sure why he's still using the javax compatible code. >> He's a small operation. Re-writing the code to use gnu namespace sounds like >> a major overhaul. Was it? >> > > I found it quite easy. In fact, in order to accommodate the > transition, I actually separated all of the code that deals directly > with the Comm API or RXTX into a helper class. The helper class was > then coded to use reflection to determine which library was available > and then instantiate the necessary objects. No direct imports of > either library are used. The main application just needs to get it's > hands on the IO streams and need not deal directly with the libraries. > Other programs may not be so simple... > > But this doesn't really help you unless your vendor forks over the > source code... > > Jeff, This may not help me directly, but I'm going to forward this thread to the vendor. I think he'll be open to making things work. Thanks again, Rick Knight From agusmunioz at gmail.com Thu Aug 7 16:39:51 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Thu, 7 Aug 2008 19:39:51 -0300 Subject: [Rxtx] How to send ack? Message-ID: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Hi, I'm still learning about serial communication and I have some doubts. I've got this question about how to do the following thing in rxtx. I have this hardware that connect to a PC using a serial port. These hardware receives data from a telephone line, proccess it, and then send it forward to the serial port. I've used a program named wincomm that shows what information is send it through the serial port and I have the nex behaviour: The hardware has a buffer where all data is stored, that cannot be sent it through the seria port. The program reads the first data send it by the hardware, and keep reading the same data always. There is a button in the application that says enable Ack, and when I click, then the hardware start to send all the stored information, and all the information is shown. I write a class, using rxtx that reads the serial port, and the same thing happens, it remains reading the same (first) data all the time. And I thing something like the enable Ack I'm missing. How can I do this enable Ack from my java code using rxtx? Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080807/e0a0f9a1/attachment-0031.html From ajmas at sympatico.ca Thu Aug 7 18:26:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 7 Aug 2008 20:26:41 -0400 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: <4BF42297-81E2-4BB8-A89F-1D43588379AE@sympatico.ca> On 6-Aug-08, at 19:40 , Bruce Boyes wrote: >> Unless I have missed the documentation for RXTX? I javadocced the >> RXTX >> source but information (to me) is minimal. >> Somewhere I got the impression that the Sun Comm API docs is, or was, >> compatible with RXTX, what is the best docs to use in conjuntion >> with RXTX >> and where may the be available? > > Yeah, this is one of my concerns/beefs. There is little documentation > for RXTX and it isn't just the same as javaxcomm. > > I would be willing to help out writing docs for RXTX! Yes really... > esp if we can fix the Bluetooth issues. If you want to contribute documentation then the best place to do that is the wiki. If there is anything missing or that could be improved on then please do so. If there are any points that you would like to see improved, for which you don't have the knowledge then ask on the mailing list for a volunteer. Andre From florianmanschwetus at gmx.de Fri Aug 8 03:04:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Fri, 08 Aug 2008 11:04:14 +0200 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Message-ID: <489C0C0E.2020401@gmx.de> Agustin Mu?oz schrieb: > Hi, I'm still learning about serial communication and I have some > doubts. I've got this question about how to do the following thing in rxtx. > I have this hardware that connect to a PC using a serial port. These > hardware receives data from a telephone line, proccess it, and then send > it forward to the serial port. I've used a program named wincomm that > shows what information is send it through the serial port and I have the > nex behaviour: > > The hardware has a buffer where all data is stored, that cannot be sent > it through the seria port. > The program reads the first data send it by the hardware, and keep > reading the same data always. > There is a button in the application that says enable Ack, and when I > click, then the hardware start to send all the stored information, and > all the information is shown. > > I write a class, using rxtx that reads the serial port, and the same > thing happens, it remains reading the same (first) data all the time. > And I thing something like the enable Ack I'm missing. > How can I do this enable Ack from my java code using rxtx? Afaik, a look at man ascii reveals: Okt Dez Hex Char 006 6 06 ACK So, i hope this will do the job: send(6); florian > > Thanks in advance > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/5b4965f8/attachment-0031.bin From agusmunioz at gmail.com Fri Aug 8 16:31:00 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 19:31:00 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <489C0C0E.2020401@gmx.de> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> Message-ID: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Hi Florian, thanks for the answer. By send(6) you mean to get the port OutputStream and write a 6? I try that but it didn't work. Any suggestion? Thanks On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < florianmanschwetus at gmx.de> wrote: > Agustin Mu?oz schrieb: > > Hi, I'm still learning about serial communication and I have some doubts. >> I've got this question about how to do the following thing in rxtx. >> I have this hardware that connect to a PC using a serial port. These >> hardware receives data from a telephone line, proccess it, and then send it >> forward to the serial port. I've used a program named wincomm that shows >> what information is send it through the serial port and I have the nex >> behaviour: >> >> The hardware has a buffer where all data is stored, that cannot be sent >> it through the seria port. >> The program reads the first data send it by the hardware, and keep reading >> the same data always. >> There is a button in the application that says enable Ack, and when I >> click, then the hardware start to send all the stored information, and all >> the information is shown. >> >> I write a class, using rxtx that reads the serial port, and the same thing >> happens, it remains reading the same (first) data all the time. And I thing >> something like the enable Ack I'm missing. >> How can I do this enable Ack from my java code using rxtx? >> > Afaik, a look at man ascii reveals: > Okt Dez Hex Char > 006 6 06 ACK > So, i hope this will do the job: > send(6); > > florian > >> >> Thanks in advance >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/7f3fba42/attachment-0030.html From agusmunioz at gmail.com Fri Aug 8 18:39:27 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 21:39:27 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Message-ID: <988288430808081739x7f9e7889id82591d5a9e2b4f6@mail.gmail.com> Ok, Florian, it works!! my problem was that I've been sending, through the OutputStream, the bytes of 6 as a string: out.write("6".getBytes()); but then I realized that you can write an int on an OuptuStream, so I tried that and It works: out.write(6); Thank you for the guidance!! On Fri, Aug 8, 2008 at 7:31 PM, Agustin Mu?oz wrote: > Hi Florian, thanks for the answer. By send(6) you mean to get the port > OutputStream and write a 6? > > I try that but it didn't work. > > Any suggestion? > > Thanks > > > On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < > florianmanschwetus at gmx.de> wrote: > >> Agustin Mu?oz schrieb: >> >> Hi, I'm still learning about serial communication and I have some doubts. >>> I've got this question about how to do the following thing in rxtx. >>> I have this hardware that connect to a PC using a serial port. These >>> hardware receives data from a telephone line, proccess it, and then send it >>> forward to the serial port. I've used a program named wincomm that shows >>> what information is send it through the serial port and I have the nex >>> behaviour: >>> >>> The hardware has a buffer where all data is stored, that cannot be sent >>> it through the seria port. >>> The program reads the first data send it by the hardware, and keep >>> reading the same data always. >>> There is a button in the application that says enable Ack, and when I >>> click, then the hardware start to send all the stored information, and all >>> the information is shown. >>> >>> I write a class, using rxtx that reads the serial port, and the same >>> thing happens, it remains reading the same (first) data all the time. And I >>> thing something like the enable Ack I'm missing. >>> How can I do this enable Ack from my java code using rxtx? >>> >> Afaik, a look at man ascii reveals: >> Okt Dez Hex Char >> 006 6 06 ACK >> So, i hope this will do the job: >> send(6); >> >> florian >> >>> >>> Thanks in advance >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/b918ab3d/attachment-0030.html From florianmanschwetus at gmx.de Sat Aug 9 00:45:43 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Sat, 09 Aug 2008 08:45:43 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4899667C.6010706@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> Message-ID: <489D3D17.9090209@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >> Florian Manschwetus wrote: >>> Ok, sounds fine for the receiving problem. >>> But why i have to wait after each byte when sending a command squence? >>> (the for loop in send command) >> >> Hi Florian, >> I'd imagine you probably don't! You could send all bytes in one go and >> RXTX would send them. The problem is most probably the other end: >> perhaps it has a really small buffer, some non-standard UART, or a >> crazy timing issue. If you attach a terminal to your output and send >> all the bytes of a command in one go they should appear no problem. >> >> Regards, >> Michael Erskine. >> > correct with a terminal on the other end it works, my idea was that this > basic baud has some influence. Could some one explain what it is for? > > Florian To make it more clear, my problem is that i can't use: outputStream.write(byte[]); => Beamer doesn't understand the sequence. (mostly no answer when he answers then *001) when i use this construct instead: for (int i = 0; i < command.length; i++) { this.outputStream.write(command[i]); try { Thread.sleep(25); } catch (InterruptedException e) { // TODO Auto-generated catch block e.printStackTrace(); } } it works nearly reliable. So what could it be? This Basic Baud is what exactly? Florian -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080809/692304ee/attachment-0030.bin From tjarvi at qbang.org Sat Aug 9 16:37:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Aug 2008 16:37:19 -0600 (MDT) Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489D3D17.9090209@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> <489D3D17.9090209@gmx.de> Message-ID: On Sat, 9 Aug 2008, Florian Manschwetus wrote: > Florian Manschwetus schrieb: >> Michael Erskine schrieb: >>> Florian Manschwetus wrote: >>>> Ok, sounds fine for the receiving problem. >>>> But why i have to wait after each byte when sending a command squence? >>>> (the for loop in send command) >>> >>> Hi Florian, >>> I'd imagine you probably don't! You could send all bytes in one go and >>> RXTX would send them. The problem is most probably the other end: perhaps >>> it has a really small buffer, some non-standard UART, or a crazy timing >>> issue. If you attach a terminal to your output and send all the bytes of a >>> command in one go they should appear no problem. >>> >>> Regards, >>> Michael Erskine. >>> >> correct with a terminal on the other end it works, my idea was that this >> basic baud has some influence. Could some one explain what it is for? >> >> Florian > To make it more clear, > my problem is that i can't use: > outputStream.write(byte[]); > => Beamer doesn't understand the sequence. (mostly no answer when he answers > then *001) > > when i use this construct instead: > > for (int i = 0; i < command.length; i++) { > this.outputStream.write(command[i]); > try { > Thread.sleep(25); > } catch (InterruptedException e) { > // TODO Auto-generated catch block > e.printStackTrace(); > } > } > > it works nearly reliable. > > So what could it be? This Basic Baud is what exactly? > I suspect you are using the 'moon protocol' and don't know it. RXTX enables this by default. The buffer on the other end is first in first out while reading. If the buffer is full, the bits are hand carried to the moon and burried. Then if the other side reads a couple bytes, two more bytes go into the buffer followed by more moon protocol. The resulting array of bytes the other side reads may appear to be scrambled until you go to the moon, get the bits and insert them in the right place. Flow control can prevent the default moon protocol and throttles the communiation by almost writing a byte at a time as need be. Hardware flow control is preferable but software flow control should also work. Read and write can appear to hang if the other side is not connected. This is why we don't enable them all the time. If you can't use flow control, you have to take care with the moon protocol and give the other side time to read. That is what your slower version of write is doing. -- Trent Jarvi tjarvi at qbang.org From rxtx at allenjb.me.uk Mon Aug 11 08:06:36 2008 From: rxtx at allenjb.me.uk (AllenJB) Date: Mon, 11 Aug 2008 15:06:36 +0100 Subject: [Rxtx] Disabling EV_RXFLAG Message-ID: <48A0476C.2090800@allenjb.me.uk> Hi all, I'm working with a device which does not use an EvtChar and need to disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an event mask of FD 01 00 00. The reference software I have uses FB 00 00 00. With the rxtx mask I get framing errors which I believe are caused when the EvtChar is received. Is there currently a way with rxtx (I've using rxtx from Java) to disable EV_RXFLAG? If not from Java, where would I start if I wanted to turn the EV_RXFLAG option off in the C code? I've had a grep of the rxtx source code, but I can't see where EV_RXFLAG is being set. Thanks in advance, AllenJB From tjarvi at qbang.org Mon Aug 11 14:17:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Aug 2008 14:17:27 -0600 (MDT) Subject: [Rxtx] Disabling EV_RXFLAG In-Reply-To: <48A0476C.2090800@allenjb.me.uk> References: <48A0476C.2090800@allenjb.me.uk> Message-ID: On Mon, 11 Aug 2008, AllenJB wrote: > Hi all, > > I'm working with a device which does not use an EvtChar and need to > disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an > event mask of FD 01 00 00. The reference software I have uses FB 00 00 > 00. With the rxtx mask I get framing errors which I believe are caused > when the EvtChar is received. > > Is there currently a way with rxtx (I've using rxtx from Java) to > disable EV_RXFLAG? > > If not from Java, where would I start if I wanted to turn the EV_RXFLAG > option off in the C code? I've had a grep of the rxtx source code, but I > can't see where EV_RXFLAG is being set. > > Thanks in advance, > > AllenJB Hi Allen, I'd look at termios.c::tcsetattr() and termios.c::FillDCB() -- Trent Jarvi tjarvi at qbang.org From superdadusa at gmail.com Tue Aug 12 13:57:32 2008 From: superdadusa at gmail.com (John Choi) Date: Tue, 12 Aug 2008 13:57:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. Message-ID: Hi all, Just let you all know I just start to learn Java. I have download the serial comm package and the source code from open source communities.. I was able to verify with the given message string via serial monitor. when the given message string sends to the serial port then the character return added to the end of string by default if I use "Hello World" however if I changed to something else other than "Hello, World" there is no character return add to the end of string. I thing the library download from rxtx.org has implemented for the special strings. I can do like "login\n" in the string message to make character return but I don't want to add this individual custom character for each command return in every static message string I send, Can any who have done this might help me? Basically, something like this,, Write and add function to the program write a command, Reads the respond from a serial device.. Function handles multiple messages, Write: "com open" Read: Welcome to my world" expected Write: "admin" Read: Password?, expected Write: "admin" Read: you are successfully login terminal, expected. And I need to add a separate function handler handles a character return add to the each command above. If anyone can help this I can do the reset? Thank you in advance, John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0026.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SerialIO.java Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0026.pl From Steffen.DETTMER at ingenico.com Wed Aug 13 02:16:38 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 13 Aug 2008 10:16:38 +0200 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: References: Message-ID: <20080813081638.GA25412@elberon.bln.de.ingenico.com> * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > I can do like "login\n" in the string message to make character > return but I don't want to add this individual custom character > for each command return in every static message string I send, and why not?! > Can any who have done this might help me? what's about with writing a small wrapper function adding the carriage return? However, this would be slow, because either you call write two times (very bad) or the string needs to be copied, \n appended and written (since you are using Java Performance probably isn't so critical). Personally I would write `"login\n"' and `username + "\n"' etc., because since it is part of the command it should be part of the command definition string. > Basically, something like this,, Write and add function to the program write > a command, Reads the respond from a serial device.. correctly reading a `line' is more difficult. If you cannot make assumptions about timeouts and/or you need to have low delay, you need to read byte wise. If you need to save CPU resources you might need to add some buffering layer that you can read byte-wise but that is reading blockwise with some small timeout (lets say for serial lines something around byte transmission time times three or so). > /* > * To change this template, choose Tools | Templates > * and open the template in the editor. > */ :) > package joliba; > > /** > * > * @author root > */ :) > // derived from SUN's examples in the javax.comm package > import java.io.*; > import java.util.*; > //import javax.comm.*; // for SUN's serial/parallel port libraries > import gnu.io.*; // for rxtxSerial library > > public class SerialIO implements Runnable, SerialPortEventListener { > static CommPortIdentifier portId; > static CommPortIdentifier saveportId; > static Enumeration portList; > InputStream inputStream; > SerialPort serialPort; > Thread readThread; You need a thread for your synchronous RPC-style protocol? > static String messageString = "Hello, world!"; > static OutputStream outputStream; > static boolean outputBufferEmptyFlag = false; > > public static void main(String[] args) { > boolean portFound = false; > String defaultPort; > > // determine the name of the serial port on several operating systems > String osname = System.getProperty("os.name","").toLowerCase(); > if ( osname.startsWith("windows") ) { > // windows > defaultPort = "COM1"; > } else if (osname.startsWith("linux")) { > // linux > defaultPort = "/dev/ttyS0"; > } else if ( osname.startsWith("mac") ) { > // mac > defaultPort = "????"; > } else { > System.out.println("Sorry, your operating system is not supported"); > return; > } Is such a construction recommended? Isn't there some abstraction (like COM1 working on any platform)? [...] > try { > // activate the OUTPUT_BUFFER_EMPTY notifier > serialPort.notifyOnOutputEmpty(true); > } catch (Exception e) { > System.out.println("Error setting event notification"); > System.out.println(e.toString()); > System.exit(-1); > } I doubt that -1 is defined, probably some 127 or so would be the result, maybe better simply `throw e'? > public void writetoport() { > System.out.println("Writing \""+messageString+"\" to "+serialPort.getName()); > try { > // write string to serial port > outputStream.write(messageString.getBytes()); > } catch (IOException e) {} > } maybe something like /** * Writes the given output string and an additional carriage * return to the current outputStream. */ public void writeStringToPort( /** The output string (without CR). */ String output ) throws IOException { String outputLine = output + "\n"; outputStream.write(outputLine.getBytes()); } ? > > public SerialIO() { > // initalize serial port > try { > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > } catch (PortInUseException e) {} if the port is in use, you continue? Wonder that this works in Java, I would assume serialPort beeing uninitialized which AFAIK is an error in Java. > try { > inputStream = serialPort.getInputStream(); > } catch (IOException e) {} > > try { > serialPort.addEventListener(this); > } catch (TooManyListenersException e) {} > > // activate the DATA_AVAILABLE notifier > serialPort.notifyOnDataAvailable(true); > > try { > // set port parameters > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > } catch (UnsupportedCommOperationException e) {} > > // start the read thread > readThread = new Thread(this); > readThread.start(); > > } I think in all those exception cases you can abort, because it is unlikely that ignoring those errors allow a successful continuation, so in this case maybe it would be better to add a throw clause to the method. > public void run() { > // first thing in the thread, we initialize the write operation > initwritetoport(); > try { > while (true) { > // write string to port, the serialEvent will read it > writetoport(); > Thread.sleep(1000); > } > } catch (InterruptedException e) {} > } Does this make sense? Your `SimpleReadApp' writes one and the same string each second? > public void serialEvent(SerialPortEvent event) { > switch (event.getEventType()) { > case SerialPortEvent.BI: > case SerialPortEvent.OE: > case SerialPortEvent.FE: > case SerialPortEvent.PE: > case SerialPortEvent.CD: > case SerialPortEvent.CTS: > case SerialPortEvent.DSR: > case SerialPortEvent.RI: > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > break; > case SerialPortEvent.DATA_AVAILABLE: > // we get here if data has been received > byte[] readBuffer = new byte[20]; > try { > // read data > while (inputStream.available() > 0) { > int numBytes = inputStream.read(readBuffer); > } > // print data > String result = new String(readBuffer); > System.out.println("Read: "+result); > } catch (IOException e) {} I doubt that this is correct. I would assume you will get a 20 bytes result always, if more bytes would be available they would be printed in a second line but if less bytes are read I'd assume that the buffer/result contains zero bytes from implicite readBuffer contents initialisation (zero is no string terminator in Java AFAIK). > break; > } > } > } oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From florianmanschwetus at gmx.de Wed Aug 13 06:09:31 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 13 Aug 2008 14:09:31 +0200 Subject: [Rxtx] someone has seen such errors? Message-ID: <48A2CEFB.90007@gmx.de> I mean my communication mostly works, but it is far from perfect could this be the reason? Florian Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/949b9947/attachment-0026.bin From superdadusa at gmail.com Wed Aug 13 08:40:32 2008 From: superdadusa at gmail.com (John Choi) Date: Wed, 13 Aug 2008 08:40:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: <20080813081638.GA25412@elberon.bln.de.ingenico.com> References: <20080813081638.GA25412@elberon.bln.de.ingenico.com> Message-ID: Thank you so much Steffen and I will try that suggestion. John On 8/13/08, Steffen DETTMER wrote: > > * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > > I can do like "login\n" in the string message to make character > > return but I don't want to add this individual custom character > > for each command return in every static message string I send, > > and why not?! > > > Can any who have done this might help me? > > what's about with writing a small wrapper function adding the > carriage return? > However, this would be slow, because either you call write two > times (very bad) or the string needs to be copied, \n appended > and written (since you are using Java Performance probably isn't > so critical). > > Personally I would write `"login\n"' and `username + "\n"' etc., > because since it is part of the command it should be part of the > command definition string. > > > Basically, something like this,, Write and add function to the program > write > > a command, Reads the respond from a serial device.. > > correctly reading a `line' is more difficult. If you cannot make > assumptions about timeouts and/or you need to have low delay, you > need to read byte wise. If you need to save CPU resources you > might need to add some buffering layer that you can read > byte-wise but that is reading blockwise with some small timeout > (lets say for serial lines something around byte transmission > time times three or so). > > > /* > > * To change this template, choose Tools | Templates > > * and open the template in the editor. > > */ > > :) > > > package joliba; > > > > /** > > * > > * @author root > > */ > > :) > > > // derived from SUN's examples in the javax.comm package > > import java.io.*; > > import java.util.*; > > //import javax.comm.*; // for SUN's serial/parallel port libraries > > import gnu.io.*; // for rxtxSerial library > > > > public class SerialIO implements Runnable, SerialPortEventListener { > > static CommPortIdentifier portId; > > static CommPortIdentifier saveportId; > > static Enumeration portList; > > InputStream inputStream; > > SerialPort serialPort; > > Thread readThread; > > You need a thread for your synchronous RPC-style protocol? > > > static String messageString = "Hello, world!"; > > static OutputStream outputStream; > > static boolean outputBufferEmptyFlag = false; > > > > public static void main(String[] args) { > > boolean portFound = false; > > String defaultPort; > > > > // determine the name of the serial port on several operating > systems > > String osname = System.getProperty("os.name","").toLowerCase(); > > if ( osname.startsWith("windows") ) { > > // windows > > defaultPort = "COM1"; > > } else if (osname.startsWith("linux")) { > > // linux > > defaultPort = "/dev/ttyS0"; > > } else if ( osname.startsWith("mac") ) { > > // mac > > defaultPort = "????"; > > } else { > > System.out.println("Sorry, your operating system is not > supported"); > > return; > > } > > Is such a construction recommended? Isn't there some abstraction > (like COM1 working on any platform)? > > [...] > > try { > > // activate the OUTPUT_BUFFER_EMPTY notifier > > serialPort.notifyOnOutputEmpty(true); > > } catch (Exception e) { > > System.out.println("Error setting event notification"); > > System.out.println(e.toString()); > > System.exit(-1); > > } > > I doubt that -1 is defined, probably some 127 or so would be the > result, maybe better simply `throw e'? > > > public void writetoport() { > > System.out.println("Writing \""+messageString+"\" to > "+serialPort.getName()); > > try { > > // write string to serial port > > outputStream.write(messageString.getBytes()); > > } catch (IOException e) {} > > } > > maybe something like > > /** > * Writes the given output string and an additional carriage > * return to the current outputStream. > */ > public void > writeStringToPort( > /** The output string (without CR). */ > String output > ) throws IOException > { > String outputLine = output + "\n"; > outputStream.write(outputLine.getBytes()); > } > > ? > > > > > public SerialIO() { > > // initalize serial port > > try { > > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > > } catch (PortInUseException e) {} > > if the port is in use, you continue? Wonder that this works in > Java, I would assume serialPort beeing uninitialized which AFAIK > is an error in Java. > > > try { > > inputStream = serialPort.getInputStream(); > > } catch (IOException e) {} > > > > try { > > serialPort.addEventListener(this); > > } catch (TooManyListenersException e) {} > > > > // activate the DATA_AVAILABLE notifier > > serialPort.notifyOnDataAvailable(true); > > > > try { > > // set port parameters > > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > } catch (UnsupportedCommOperationException e) {} > > > > // start the read thread > > readThread = new Thread(this); > > readThread.start(); > > > > } > > I think in all those exception cases you can abort, because it is > unlikely that ignoring those errors allow a successful > continuation, so in this case maybe it would be better to add a > throw clause to the method. > > > public void run() { > > // first thing in the thread, we initialize the write operation > > initwritetoport(); > > try { > > while (true) { > > // write string to port, the serialEvent will read it > > writetoport(); > > Thread.sleep(1000); > > } > > } catch (InterruptedException e) {} > > } > > Does this make sense? Your `SimpleReadApp' writes one and the > same string each second? > > > public void serialEvent(SerialPortEvent event) { > > switch (event.getEventType()) { > > case SerialPortEvent.BI: > > case SerialPortEvent.OE: > > case SerialPortEvent.FE: > > case SerialPortEvent.PE: > > case SerialPortEvent.CD: > > case SerialPortEvent.CTS: > > case SerialPortEvent.DSR: > > case SerialPortEvent.RI: > > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > > break; > > case SerialPortEvent.DATA_AVAILABLE: > > // we get here if data has been received > > byte[] readBuffer = new byte[20]; > > try { > > // read data > > while (inputStream.available() > 0) { > > int numBytes = inputStream.read(readBuffer); > > } > > // print data > > String result = new String(readBuffer); > > System.out.println("Read: "+result); > > } catch (IOException e) {} > > I doubt that this is correct. I would assume you will get a 20 > bytes result always, if more bytes would be available they would > be printed in a second line but if less bytes are read I'd assume > that the buffer/result contains zero bytes from implicite > readBuffer contents initialisation (zero is no string terminator > in Java AFAIK). > > > break; > > } > > } > > } > > oki, > > Steffen > > About Ingenico Throughout the world businesses rely on Ingenico for secure > and expedient electronic transaction acceptance. Ingenico products leverage > proven technology, established standards and unparalleled ergonomics to > provide optimal reliability, versatility and usability. This comprehensive > range of products is complemented by a global array of services and > partnerships, enabling businesses in a number of vertical sectors to accept > transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged > information. If you are not the addressee or authorized to receive this for > the addressee, you must not use, copy, disclose or take any action based on > this message or any information herein. If you have received this message in > error, please advise the sender immediately by reply e-mail and delete this > message. Thank you for your cooperation. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/73c4135c/attachment-0025.html From ajmas at sympatico.ca Sat Aug 16 07:15:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 09:15:41 -0400 Subject: [Rxtx] someone has seen such errors? In-Reply-To: <48A2CEFB.90007@gmx.de> References: <48A2CEFB.90007@gmx.de> Message-ID: <43B5E8DA-1D93-4D90-809B-AAF35FF724C5@sympatico.ca> On 13-Aug-08, at 08:09 , Florian Manschwetus wrote: > I mean my communication mostly works, but it is far from perfect > could this be the reason? > > Florian > > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control Judging by the error messages this looks related to the driver you are using. Do a search for the following string with you favourite search engine, it should turn up a few hits: ftdi_set_termios FAILED to set databits/stopbits/parity Andre From ajmas at sympatico.ca Sat Aug 16 19:12:04 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 21:12:04 -0400 Subject: [Rxtx] Using SerialPortEvent? Message-ID: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Hi, Could someone tell me how I should be using the SerialPortEvent? Am I meant to be waiting for data and then simply reading from the inputstream? If this is the case why no just block on an inputstream read? Andr? From tjarvi at qbang.org Sat Aug 16 19:41:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 16 Aug 2008 19:41:13 -0600 (MDT) Subject: [Rxtx] Using SerialPortEvent? In-Reply-To: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> References: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Message-ID: On Sat, 16 Aug 2008, Andre-John Mas wrote: > Hi, > > Could someone tell me how I should be using the SerialPortEvent? Am I > meant to be waiting for data and then simply reading from the > inputstream? If this is the case why no just block on an inputstream > read? > Polling for data is fine also. It really depends upon what you are trying to do. For instance, if you require x bytes before reading, you can start polling after data is available. If you read on the same thread as your GUI and are waiting for data in a read, the results may be less than desirable. Java programming is 'usually' event driven rather than polling based. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sat Aug 16 20:10:39 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 22:10:39 -0400 Subject: [Rxtx] Using SerialPortEvent? In-Reply-To: References: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Message-ID: <3E495D4C-BB28-4845-A6AB-984C9A826BDF@sympatico.ca> On 16-Aug-08, at 21:41 , Trent Jarvi wrote: > On Sat, 16 Aug 2008, Andre-John Mas wrote: > >> Hi, >> >> Could someone tell me how I should be using the SerialPortEvent? Am I >> meant to be waiting for data and then simply reading from the >> inputstream? If this is the case why no just block on an inputstream >> read? >> > > Polling for data is fine also. It really depends upon what you are > trying to do. For instance, if you require x bytes before reading, > you can start polling after data is available. If you read on the > same thread as your GUI and are waiting for data in a read, the > results may be less than desirable. > > Java programming is 'usually' event driven rather than polling based. Sounds good. I thought I would use this opportunity to provide a event based version of the TwoWaySerialComm example. Could you just validate it before I add it to the Wiki: package ajmas74.experimental; import gnu.io.CommPort; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; import gnu.io.SerialPortEvent; import gnu.io.SerialPortEventListener; import java.io.IOException; import java.io.InputStream; import java.io.OutputStream; /** * This version of the TwoWaySerialComm example makes use of the * SerialPortEventListener to avoid polling. * * @author ajmas * */ public class TwoWaySerialComm { public TwoWaySerialComm() { super(); } void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { CommPort commPort = portIdentifier.open(this.getClass().getName(),2000); if ( commPort instanceof SerialPort ) { SerialPort serialPort = (SerialPort) commPort; serialPort .setSerialPortParams (57600 ,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); (new Thread(new SerialWriter(out))).start(); serialPort.addEventListener(new SerialReader(in)); } else { System.out.println("Error: Only serial ports are handled by this example."); } } } /** * Handles the input coming from the serial port. A new line character * is treated as the end of a block in this example. */ public static class SerialReader implements SerialPortEventListener { private InputStream in; private byte[] buffer = new byte[1024]; public SerialReader ( InputStream in ) { this.in = in; } public void serialEvent(SerialPortEvent arg0) { int data; try { int len = 0; while ( ( data = in.read()) > -1 ) { if ( data != '\n' ) { break; } buffer[len++] = (byte) data; } System.out.print(new String(buffer,0,len)); } catch ( IOException e ) { e.printStackTrace(); System.exit(-1); } } } /** */ public static class SerialWriter implements Runnable { OutputStream out; public SerialWriter ( OutputStream out ) { this.out = out; } public void run () { try { int c = 0; while ( ( c = System.in.read()) > -1 ) { this.out.write(c); } } catch ( IOException e ) { e.printStackTrace(); System.exit(-1); } } } public static void main ( String[] args ) { try { (new TwoWaySerialComm()).connect("COM3"); } catch ( Exception e ) { e.printStackTrace(); } } } From lfarkas at lfarkas.org Tue Aug 19 07:32:59 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Tue, 19 Aug 2008 15:32:59 +0200 Subject: [Rxtx] JNI or CNI Message-ID: <48AACB8B.9060606@lfarkas.org> hi, what is the current recommended way to rxtx on linux JNI or it's better to use CNI? is the CNI version fully functional and the same level as the JNI? i currently try to make a rhel/centos/fedora rpm for rxtx but has many problems with the standard dir structure. yours. -- Levente "Si vis pacem para bellum!" From lfarkas at lfarkas.org Tue Aug 19 08:47:34 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Tue, 19 Aug 2008 16:47:34 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel Message-ID: <48AADD06.7040809@lfarkas.org> hi, newer or not so newer linux kernel do not contain the UTS_RELEASE so the current rxtx is not compile on the latest kernels. even if it's commented out in the cvs configure there are other places. i attcahed a patch which fix it (or at least doesn't cause error at non-debug build). ps. is there any plan to the new 2.1-8 release in the near future? there are many changes (at least the license change in all file and in this case create a diff is very difficult)? the latest release more then 2 years old:-( -- Levente "Si vis pacem para bellum!" -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-2.1-uts.patch Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080819/ab5d38ac/attachment-0019.pl From ajmas at sympatico.ca Tue Aug 19 16:21:53 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 19 Aug 2008 18:21:53 -0400 Subject: [Rxtx] Event based example Message-ID: <24735BFB-B088-4B84-8173-FE98DF63B12F@sympatico.ca> Hi, I have just posted an example of using SerialPortEventListener in the Wiki: http://rxtx.qbang.org/wiki/index.php/Event_Based_Two_Way_Communication If you see any issues please could you let me know, or makes the changes. Andre From Martin.Oberhuber at windriver.com Fri Aug 22 04:02:24 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 22 Aug 2008 12:02:24 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <48AADD06.7040809@lfarkas.org> References: <48AADD06.7040809@lfarkas.org> Message-ID: <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> Farkas, there are indeed efforts to get a new RXTX release out the door. Your experience as a package maintainer would likely be helpful during these efforts, since I'd think it makes sense to keep the patches minimal that you must make to have the source compile in your environment. What are the things that you find problematic, apart from the UTS thing that you have mentioned before? What is the timing that you have in mind for your package? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Farkas Levente > Sent: Tuesday, August 19, 2008 4:48 PM > To: rxtx at qbang.org > Subject: [Rxtx] UTS_RELEASE not defined in newer kernel > > hi, > newer or not so newer linux kernel do not contain the > UTS_RELEASE so the > current rxtx is not compile on the latest kernels. even if it's > commented out in the cvs configure there are other places. > i attcahed a patch which fix it (or at least doesn't cause error at > non-debug build). > > ps. is there any plan to the new 2.1-8 release in the near > future? there > are many changes (at least the license change in all file and in this > case create a diff is very difficult)? the latest release more then 2 > years old:-( > > -- > Levente "Si vis pacem para bellum!" > From lfarkas at lfarkas.org Fri Aug 22 04:36:26 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Fri, 22 Aug 2008 12:36:26 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> References: <48AADD06.7040809@lfarkas.org> <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> Message-ID: <48AE96AA.6090505@lfarkas.org> hi, the packages already build for fedora-9 and centos-5 and here: http://www.lfarkas.org/linux/packages/ what i've to patch, the UTS, the configure script, but it's already fixed in the cvs (in another way) and the loadlibrary. the reasons for last one can be found here: https://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_files_that_use_JNI after we test it i'd like to add these packages to fedora and epel main repository (that's why it's be useful a new release after 2 years:-) imho versions are cheap and why not just release 2.1-8? the real code changes are minimal and if something critical bug found still can release 2.1-9:-) ps. and would be better to use simple number for version like 2.1-7 rather then 2.1-7v2. Oberhuber, Martin wrote: > Farkas, > > there are indeed efforts to get a new RXTX release out the > door. Your experience as a package maintainer would likely > be helpful during these efforts, since I'd think it makes > sense to keep the patches minimal that you must make to > have the source compile in your environment. > > What are the things that you find problematic, apart from > the UTS thing that you have mentioned before? > > What is the timing that you have in mind for your package? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >> On Behalf Of Farkas Levente >> Sent: Tuesday, August 19, 2008 4:48 PM >> To: rxtx at qbang.org >> Subject: [Rxtx] UTS_RELEASE not defined in newer kernel >> >> hi, >> newer or not so newer linux kernel do not contain the >> UTS_RELEASE so the >> current rxtx is not compile on the latest kernels. even if it's >> commented out in the cvs configure there are other places. >> i attcahed a patch which fix it (or at least doesn't cause error at >> non-debug build). >> >> ps. is there any plan to the new 2.1-8 release in the near >> future? there >> are many changes (at least the license change in all file and in this >> case create a diff is very difficult)? the latest release more then 2 >> years old:-( >> >> -- >> Levente "Si vis pacem para bellum!" >> -- Levente "Si vis pacem para bellum!" From tjarvi at qbang.org Fri Aug 22 18:50:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Aug 2008 18:50:32 -0600 (MDT) Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <48AE96AA.6090505@lfarkas.org> References: <48AADD06.7040809@lfarkas.org> <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> <48AE96AA.6090505@lfarkas.org> Message-ID: Hi Farkas, The v2 was simply the second build - no code changes. We are comming out with a new release shortly. I would encourage working with distros as you are. The building of rxtx turns out to be a bottle neck in quick releases. We do want stable releases that work for a year or more but I would have no problems with quicker cycles on developing work. I would have no problem working with someone that did builds that receive less testing more often but they do have to come out for multiple platforms from this end. Thanks for the links. On Fri, 22 Aug 2008, Farkas Levente wrote: > hi, > the packages already build for fedora-9 and centos-5 and here: > http://www.lfarkas.org/linux/packages/ > what i've to patch, the UTS, the configure script, but it's already > fixed in the cvs (in another way) and the loadlibrary. the reasons for > last one can be found here: > https://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_files_that_use_JNI > after we test it i'd like to add these packages to fedora and epel main > repository (that's why it's be useful a new release after 2 years:-) > imho versions are cheap and why not just release 2.1-8? the real code > changes are minimal and if something critical bug found still can > release 2.1-9:-) > > ps. and would be better to use simple number for version like 2.1-7 > rather then 2.1-7v2. > > Oberhuber, Martin wrote: >> Farkas, >> >> there are indeed efforts to get a new RXTX release out the >> door. Your experience as a package maintainer would likely >> be helpful during these efforts, since I'd think it makes >> sense to keep the patches minimal that you must make to >> have the source compile in your environment. >> >> What are the things that you find problematic, apart from >> the UTS thing that you have mentioned before? >> >> What is the timing that you have in mind for your package? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >>> On Behalf Of Farkas Levente >>> Sent: Tuesday, August 19, 2008 4:48 PM >>> To: rxtx at qbang.org >>> Subject: [Rxtx] UTS_RELEASE not defined in newer kernel >>> >>> hi, >>> newer or not so newer linux kernel do not contain the >>> UTS_RELEASE so the >>> current rxtx is not compile on the latest kernels. even if it's >>> commented out in the cvs configure there are other places. >>> i attcahed a patch which fix it (or at least doesn't cause error at >>> non-debug build). >>> >>> ps. is there any plan to the new 2.1-8 release in the near >>> future? there >>> are many changes (at least the license change in all file and in this >>> case create a diff is very difficult)? the latest release more then 2 >>> years old:-( >>> >>> -- >>> Levente "Si vis pacem para bellum!" >>> > > > From andy at triera.net Sat Aug 23 15:17:44 2008 From: andy at triera.net (Andy Rozman) Date: Sat, 23 Aug 2008 21:17:44 +0000 Subject: [Rxtx] port not identified on FreeBSD In-Reply-To: References: Message-ID: <48B07E78.2030306@triera.net> Hi ! I have one small problem... I have started using FreeBSD in last few days and I have come accross a problem with rxtx on FreeBSD. I am using usb-to-serial converter, which is identified under FreeBSD without problem as ucom0, and creates link under /dev called ttyU0, which is correct way to be done under FreeBSD (if device would be unidentified it would be called ugen0 - as usb generic). Problem is that I say to rxtx to get my all serial ports this one is not among them. Which names are permissable under linux-like implementations? Which will be accepted as serial ports? Andy From tjarvi at qbang.org Sat Aug 23 13:57:45 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 23 Aug 2008 13:57:45 -0600 (MDT) Subject: [Rxtx] port not identified on FreeBSD In-Reply-To: <48B07E78.2030306@triera.net> References: <48B07E78.2030306@triera.net> Message-ID: On Sat, 23 Aug 2008, Andy Rozman wrote: > Hi ! > > I have one small problem... I have started using FreeBSD in last few > days and I have come accross a problem with rxtx on FreeBSD. > > I am using usb-to-serial converter, which is identified under FreeBSD > without problem as ucom0, and creates link under /dev called > ttyU0, which is correct way to be done under FreeBSD (if device would be > unidentified it would be called ugen0 - as usb generic). Problem is that > I say to rxtx to get my all serial ports this one is not among them. > Which names are permissable under linux-like implementations? Which will > be accepted as serial ports? > > Andy > Thanks Andy! We will add ttyU* to FreeBSD. For now you can use properties to enable the port. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting#How_does_rxtx_detect_ports.3F__Can_I_override_it.3F The fix: diff -u -r1.16.2.59 RXTXCommDriver.java --- RXTXCommDriver.java 18 Nov 2007 22:32:41 -0000 1.16.2.59 +++ RXTXCommDriver.java 23 Aug 2008 19:55:25 -0000 @@ -644,6 +644,7 @@ { String[] Temp = { "ttyd", //general purpose serial ports + "ttyU", //general purpose USB serial ports "cuaa", //dialout serial ports "ttyA", //Specialix SI/XIO dialin ports "cuaA", //Specialix SI/XIO dialout ports -- Trent Jarvi tjarvi at qbang.org From rick_knight at rlknight.com Mon Aug 4 13:25:10 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Mon, 04 Aug 2008 12:25:10 -0700 Subject: [Rxtx] Sun's Comm API? Message-ID: <48975796.4010600@rlknight.com> I have an application that requires the javax compatible version of RXTX and Sun's comm api. I've been able to download and extract the version of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api anywhere. Can someone tell me where I can find it? Or maybe send me a copy? Also, when I try to build RXTX, configure and make complete successfully but make install failes with this error libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 I've never come accross this error before. How can I get past it? Thanks, Rick From bboyes at systronix.com Mon Aug 4 19:10:01 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:10:01 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48975796.4010600@rlknight.com> References: <48975796.4010600@rlknight.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/cb9c6167/attachment-0035.html From bboyes at systronix.com Mon Aug 4 19:12:37 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:12:37 -0600 Subject: [Rxtx] Towards an RXTX release - CSR BT/USB chipset In-Reply-To: <488FB7E7.8000802@gmail.com> References: <460801A4097E3D4CA04CC64EE648584806C56CF0@ism-mail03.corp.ad.wrs.com> <13557-75390@sneakemail.com> <20980-23424@sneakemail.com> <488FB7E7.8000802@gmail.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/52236088/attachment-0035.html From tjarvi at qbang.org Mon Aug 4 19:42:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 19:42:21 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: On Mon, 4 Aug 2008, Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: > I have an application that requires the javax compatible > version of RXTX > and Sun's comm api. I've been able to download and extract > the version > of RXTX that I need (2.0-7pre2) but I can't find Sun's camm > api > anywhere. Can someone tell me where I can find it? Or maybe > send me a > > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm port > support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have just > a ZIP with only the .class JAR file - no source or docs), has a readme > with these comments: > > This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release.? The 2.0.3 release itself is > no longer distributed.? comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project.? The RxTx project (http://www.rxtx.org ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org) was opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support.? Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins.? Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > ? > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > I hope that is helpful! > It would be nice to work with Sun to resolve those longstanding issues. But it may not be practical unless the process goes as fast and painless as the grandfathering of commapi did. Another option may be the old kaffe extensions that moved to gnu classpathx. These don't have the native libraries but should provide the 2.0 interface and the javax.comm.properties mechansim for SPI. http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Mon Aug 4 20:23:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Mon, 04 Aug 2008 20:23:57 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4897B9BD.5070809@ergotech.com> Has there been any work/would it be possible, to layer a javacomm look-alike on top of the GNU code? The goal is not to move the javax code forward, but to emulate the "legacy" javax packages for people who still need this. Jim Trent Jarvi wrote: > On Mon, 4 Aug 2008, Bruce Boyes wrote: > >> At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible >> version of RXTX >> and Sun's comm api. I've been able to download and extract >> the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm >> api >> anywhere. Can someone tell me where I can find it? Or maybe >> send me a >> >> >> javaxcomm has had a sort of on-again off-again history. The windoze >> version has been languishing for years (literally) but there are newer >> versions for other OS's. >> >> We try to keep links on one of our help pages current: >> http://www.practicalembeddedjava.com/tools/javatools_list.html >> which gets you to here: >> http://java.sun.com/products/javacomm/ >> where it says in fact they no longer even support Windows and Mac: >> "Implementations of the API are currently available for Solaris SPARC, >> Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so >> someone could support it. But I guess that's part of the reason RXTX >> exists! >> >> So one of Sun's own products, SunSPOT, has to use RXTX to get comm port >> support. >> >> The version we use is 2.0 from 11/15/1998. I have posted it on our >> website, which is within the terms of the license agreement contained >> therein (as I understand it). >> >> The last version of javaxcomm for Windows, 2.0.3, (for which I have just >> a ZIP with only the .class JAR file - no source or docs), has a readme >> with these comments: >> >> This distribution contains the comm.jar file original part >> of the COMMAPI 2.0.3 release. The 2.0.3 release itself is >> no longer distributed. comm.jar, which contains the comm >> API java class files (eg. Sun's binary implementation of the >> interface classes), is being made available, unsupported, >> with no obligation to fix bugs, at the request of the RXTX >> project. The RxTx project (http://www.rxtx.org ), uses the >> comm.jar class files, but provides their own native library >> components to provide support for other platforms. >> >> The 2.0.3 comm.jar is being provided in this way because >> as of COMMAPI 3.x, the java binary implementation forked and >> became incompatible with the RxTx project's native code. >> Due to the lack of a clear business case, and to resource >> constraints, no additional resources are being >> provided to provide an alternative engineering solution >> at the time of writing. >> >> RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: >> >> Ultimately the COMMAPI would be better served if a Java >> Community Process JSR (http://www.jcp.org) was opened and >> the COMMAPI was rearchitected to provide a more pluggable >> framework to improve cross-platform support. Such an >> architecture would embody a better defined and better >> documented SPI interface, including a way for comm. ports >> to be revealed to the client application through the API >> via platform-aware plugins. Similarly, native code used >> to access comm port in general could be handled more >> flexibly using a plugin model, whereby on any platform, >> multiple native modules could be in use simultaneously. >> >> Since there are now various ways serial ports can be implemented >> and accessed, modular comm. port JNI native libraries would be >> of benefit insofar as removing the burden of over-generalization >> from any single native component, or inversely, by relieving the >> implicit constraint that comm. drivers be accessed only via a >> monolithic mechanism, such as the UNIX vnode interface. >> >> paul.klissner at sun.com >> 6/10/06 >> >> I hope that is helpful! >> > > It would be nice to work with Sun to resolve those longstanding issues. > But it may not be practical unless the process goes as fast and painless > as the grandfathering of commapi did. > > Another option may be the old kaffe extensions that moved to gnu > classpathx. These don't have the native libraries but should provide > the 2.0 interface and the javax.comm.properties mechansim for SPI. > > http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Mon Aug 4 21:09:15 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 21:09:15 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? Message-ID: Hi Jim, I will not step into the javax.comm namespace without Sun's explicite permission. I fully understand the pain point you are trying to address. In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm Linux) - which remains an integral part of rxtx. At the time it was a win for Sun and rxtx. The Sun commapi license is/was fairly clear that rxtx should not step into that namespace. It made sense as Sun was active in that space and rxtx may go into another namespace - it was an experiment in working with Sun. This may sound silly looking at something that happened almost 10 years ago. In a community of respect which Sun helped create, there is no question about what to do. I hope eventually Sun will step up and do a right thing too. I agree that this is hurting the API more than helping it. There are also questions about how to replace the API in the long term which includes HID support which isn't going well so far. Others that can't even look at Sun's javax.comm today and can look at Kaffe's contribution to classpathx can easily work around such restrictions. On Mon, 4 Aug 2008, Jim Redman wrote: > Has there been any work/would it be possible, to layer a javacomm > look-alike on top of the GNU code? > > The goal is not to move the javax code forward, but to emulate the > "legacy" javax packages for people who still need this. > > Jim > > Trent Jarvi wrote: >> >> It would be nice to work with Sun to resolve those longstanding issues. >> But it may not be practical unless the process goes as fast and painless >> as the grandfathering of commapi did. >> >> Another option may be the old kaffe extensions that moved to gnu >> classpathx. These don't have the native libraries but should provide >> the 2.0 interface and the javax.comm.properties mechansim for SPI. >> >> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From florianmanschwetus at gmx.de Tue Aug 5 05:04:46 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 13:04:46 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: References: <48971C1F.9020806@gmx.de> Message-ID: <489833CE.1040801@gmx.de> Just look at sendCommand in this method I have to place a Thread.sleep(20) after each byte send to get working. Even the event based receive doesn't work fine but this could be may stupidness. The specifikation document (it is on the last pages of the manual) for the beamer could be found on: http://www.optoma.co.uk/support.aspx Florian Manschwetus Trent Jarvi schrieb: > > Hi Florian > > Sorry for the top post in advance. I worry you may not see my answer > under all your code :) > > I have not received this email before. This is 500k of code which I > don't have time to read. I can spend about 5 min on each hobby email > and still get to work in the morning. I have a couple suggestions for > how to get an answer. > > First, cut out your comments and extra code so you can demonstrate the > question (I might even glance and see what is wrong then). Don't go for > a working final product. Isolate the problem using a simple program and > then ask with that as an example. If I did what you just did, I'd have > to post 3/4 of a million lines of code :) > > Second, join the rxtx mail-list and ask there. This will give you 100x > more eyes. I'll also read and try to follow. > > -- > taj > > > > On Mon, 4 Aug 2008, Florian Manschwetus wrote: > >> It could be that my university account is blocked by filters so >> resending from here. >> >> >> Topic is to control Optoma HD80 beamer using rs232 serial chat. >> This code is able to detect power state and switch the beamer on / off. >> connected is the beamer using a digitus usb 2.0 serial adapter with an >> FT232 USB-Serial adapter the systems architecture is amd64. >> >> Please take a look in the sendCommand routine i have to place theire >> those Thread.sleep to get it working. >> Now the question is this correct or is there a better way to get this >> working correctly? >> >> In the javadoc coming with the install i found this: >> setBaudBase >> >> public boolean setBaudBase(int BaudBase) >> throws UnsupportedCommOperationException, >> java.io.IOException >> >> Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 >> before using. >> >> could this explain the error? >> I attached my java source and the protocol description for the beamer >> (available on vendor website). >> >> thx, >> Florian Manschwetus >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: TestRS232.java Type: text/x-java Size: 9143 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0070.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0071.bin From michael.erskine at ketech.com Tue Aug 5 05:53:49 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Tue, 5 Aug 2008 12:53:49 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489833CE.1040801@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> > Just look at sendCommand in this method I have to place a > Thread.sleep(20) after each byte send to get working. Even the event > based receive doesn't work fine but this could be may stupidness. Hi Florian, Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. Regards, Michael Erskine. From florianmanschwetus at gmx.de Tue Aug 5 07:28:15 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:28:15 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> Message-ID: <4898556F.8000208@gmx.de> Michael Erskine schrieb: >> Just look at sendCommand in this method I have to place a >> Thread.sleep(20) after each byte send to get working. Even the event >> based receive doesn't work fine but this could be may stupidness. > > Hi Florian, > > Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. > > Regards, > Michael Erskine. > Ok, sounds fine for the receiving problem. But why i have to wait after each byte when sending a command squence? (the for loop in send command) Florian > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/284f350c/attachment-0034.bin From florianmanschwetus at gmx.de Tue Aug 5 07:44:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:44:14 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <4898592E.2020908@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >>> Just look at sendCommand in this method I have to place a >>> Thread.sleep(20) after each byte send to get working. Even the event >>> based receive doesn't work fine but this could be may stupidness. >> >> Hi Florian, >> >> Yes, naturally you'll have to wait for a response from the other end. >> Why not wait for notification from the event thread perhaps using a >> BlockingDeque rather than your LinkedList. Generally I >> try to decouple all input and output streams: in your case your >> application is operating synchronously like the "expect" program >> (http://expect.nist.gov/) so waits (or timeouts) will need to be >> factored in. >> >> Regards, >> Michael Erskine. >> > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) > > Florian Furthermore there is this basic baud with this confusing javadoc entry: public boolean setBaudBase(int BaudBase) throws UnsupportedCommOperationException, java.io.IOException Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 before using. maybe this could explain something Florian >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/006c7425/attachment-0034.bin From jredman at ergotech.com Tue Aug 5 09:13:36 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 05 Aug 2008 09:13:36 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: Message-ID: <48986E20.3060104@ergotech.com> Trent, So two issues: 1) Technically I'm still not sure how easy/practical a layer would be. The problems are always classes like listeners, and wrapping returns of gnu.io classes. I really see it as a "delegate" type of concept. Any thoughts or ideas of the practicality of this approach? The idea is not to modify RXTX. 2) Javax. The javax namespace does seem to be in widespread use outside of Sun (the same is true for the java namespace). The classpath extensions, or some other location, should be interested in a JavaComm implementation even if it does have dependencies on RXTX. Would you have any philosophical objection to an approach like that? Of course, I suspect it might be better if someone with that authority at Sun would admit that the javax namespace is already in the wild and that there is no problem with it being used within RXTX. Jim Trent Jarvi wrote: > Hi Jim, > > I will not step into the javax.comm namespace without Sun's explicite > permission. I fully understand the pain point you are trying to address. > > In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm > Linux) - which remains an integral part of rxtx. At the time it was a win for > Sun and rxtx. > > The Sun commapi license is/was fairly clear that rxtx should not step into that > namespace. It made sense as Sun was active in that space and rxtx may go into > another namespace - it was an experiment in working with Sun. > > This may sound silly looking at something that happened almost 10 years ago. > In a community of respect which Sun helped create, there is no question about > what to do. I hope eventually Sun will step up and do a right thing too. > > I agree that this is hurting the API more than helping it. There are also > questions about how to replace the API in the long term which includes HID > support which isn't going well so far. > > Others that can't even look at Sun's javax.comm today and can look at Kaffe's > contribution to classpathx can easily work around such restrictions. > > On Mon, 4 Aug 2008, Jim Redman wrote: > >> Has there been any work/would it be possible, to layer a javacomm >> look-alike on top of the GNU code? >> >> The goal is not to move the javax code forward, but to emulate the >> "legacy" javax packages for people who still need this. >> >> Jim >> >> Trent Jarvi wrote: >>> It would be nice to work with Sun to resolve those longstanding issues. >>> But it may not be practical unless the process goes as fast and painless >>> as the grandfathering of commapi did. >>> >>> Another option may be the old kaffe extensions that moved to gnu >>> classpathx. These don't have the native libraries but should provide >>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>> >>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From sandeep at genevasoftech.com Tue Aug 5 11:18:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Tue, 05 Aug 2008 22:48:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <48988B6C.5080409@genevasoftech.com> Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. *-- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/ad20f1cb/attachment-0034.html From Martin.Oberhuber at windriver.com Tue Aug 5 13:30:17 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Tue, 5 Aug 2008 21:30:17 +0200 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Sandeep, shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on Sol7 but I've successfully run it on Sol9 and Sol10. Or is your request really about a native 64bit variant? I'm afraid that then you're out of luck since I think that quite a bit of RXTX is not yet ready for 64 bit. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Sandeep Kumar K Sent: Tuesday, August 05, 2008 7:19 PM To: rxtx at qbang.org Subject: [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so for Solaris 9 Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. -- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/81b7f988/attachment-0034.html From tjarvi at qbang.org Tue Aug 5 22:38:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 22:38:34 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 5 Aug 2008, Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built > on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid that > then > you're out of luck since I think that quite a bit of RXTX is not yet > ready > for 64 bit. > While rxtx-2.1-7 probably has problems, The CVS code should be OK for 64 bit Solaris. If it isn't, let me know and I'll find which patch is missing. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Aug 5 23:13:00 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 23:13:00 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48986E20.3060104@ergotech.com> References: <48986E20.3060104@ergotech.com> Message-ID: On Tue, 5 Aug 2008, Jim Redman wrote: > Trent, > > So two issues: > > 1) Technically I'm still not sure how easy/practical a layer would be. The > problems are always classes like listeners, and wrapping returns of gnu.io > classes. I really see it as a "delegate" type of concept. Any thoughts or > ideas of the practicality of this approach? The idea is not to modify RXTX. I have not put too much thought into this. I assume you want what rxtx 2.0 provided to tie into javax.comm implementations. More classes could be added to rxtx 2.1-7 for SPI support. Maintaining rxtx-2.0 could also be handed to someone if they like. > > 2) Javax. The javax namespace does seem to be in widespread use outside of > Sun (the same is true for the java namespace). The classpath extensions, or > some other location, should be interested in a JavaComm implementation even > if it does have dependencies on RXTX. Would you have any philosophical > objection to an approach like that? > No problems. Classpathx would be a possible place to do it. I'd suggest thinking twice about what this involves in practical terms. You would be wanting to revive the 2.0 API while Sun is at 3.0 and grandfathering the JSR. This undermines the main reason (established api) for using the javax.comm namespace and does not leave such a project in a good position. The only win I see here is maintaining support for applications that can't migrate namespaces. Not that that isn't important. At some point it is going to be less work to just edit the bytecode :) Such a javax.comm effort would also be signing up new projects that decided to use the work up for concerns they probably will not understand or expect. That probably isn't a good path to facilitate for new projects at this time. We will put a good faith effort to work well with others but keep in mind the project has limited bandwidth for such efforts. > Of course, I suspect it might be better if someone with that authority at Sun > would admit that the javax namespace is already in the wild and that there is > no problem with it being used within RXTX. > > Jim > > Trent Jarvi wrote: >> Hi Jim, >> >> I will not step into the javax.comm namespace without Sun's explicite >> permission. I fully understand the pain point you are trying to address. >> >> In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java >> Comm Linux) - which remains an integral part of rxtx. At the time it was a >> win for Sun and rxtx. >> >> The Sun commapi license is/was fairly clear that rxtx should not step into >> that namespace. It made sense as Sun was active in that space and rxtx may >> go into another namespace - it was an experiment in working with Sun. >> >> This may sound silly looking at something that happened almost 10 years >> ago. In a community of respect which Sun helped create, there is no >> question about what to do. I hope eventually Sun will step up and do a >> right thing too. >> >> I agree that this is hurting the API more than helping it. There are also >> questions about how to replace the API in the long term which includes HID >> support which isn't going well so far. >> >> Others that can't even look at Sun's javax.comm today and can look at >> Kaffe's contribution to classpathx can easily work around such >> restrictions. >> >> On Mon, 4 Aug 2008, Jim Redman wrote: >> >>> Has there been any work/would it be possible, to layer a javacomm >>> look-alike on top of the GNU code? >>> >>> The goal is not to move the javax code forward, but to emulate the >>> "legacy" javax packages for people who still need this. >>> >>> Jim >>> >>> Trent Jarvi wrote: >>>> It would be nice to work with Sun to resolve those longstanding issues. >>>> But it may not be practical unless the process goes as fast and painless >>>> as the grandfathering of commapi did. >>>> >>>> Another option may be the old kaffe extensions that moved to gnu >>>> classpathx. These don't have the native libraries but should provide >>>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>>> >>>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From sandeep at genevasoftech.com Wed Aug 6 00:03:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Wed, 06 Aug 2008 11:33:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: <48993EB8.30107@genevasoftech.com> Thank you Mr. Martin for your suggestion. The native file which is given in rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am getting the following error . Any suggestions to solve this issue. I am using Solaris SPARC 64 bit machine. ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) thrown while loading gnu.io.RXTXCommDriver Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(Unknown Source) at java.lang.ClassLoader.loadLibrary(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) at com.ReadFromModem.main(ReadFromModem.java:84) * * *Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid > that then > you're out of luck since I think that quite a bit of RXTX is not yet ready > for 64 bit. > > Cheers, > -- > *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > ------------------------------------------------------------------------ > *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On > Behalf Of *Sandeep Kumar K > *Sent:* Tuesday, August 05, 2008 7:19 PM > *To:* rxtx at qbang.org > *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so > for Solaris 9 > > Hi, > > Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 > bit machine. The librxtxSerial.so given in website is for Solaris 8. > > *-- > > Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/1e920343/attachment-0034.html From tjarvi at qbang.org Wed Aug 6 00:21:42 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 00:21:42 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <48993EB8.30107@genevasoftech.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> <48993EB8.30107@genevasoftech.com> Message-ID: Hi Sandeep You may be out of luck unless you can compile the 2.1 src in CVS (requires gnu make and gcc). But you could try the ToyBox(R)(TM) which is a collection of WiLdLy untested cross compiled 2.1-7 binaries covering everything from the ibm z series to embeded arm/ppc. To give an idea how poorly these are tested, I don't even know if z series machines have a serial port. ftp://www.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Solaris They should at least match the binary types. Actually, I think if you use the rxtx jar from CVS with that file, it should 'work' as the fix for 64 bits was in java not the native code. You could just cd rxtx*/src; javac *.java then jar -cf RXTXcomm.jar `find -name \*.class` to create the hybrid which will complain about version information a bit. On Wed, 6 Aug 2008, Sandeep Kumar K wrote: > Thank you Mr. Martin for your suggestion. The native file which is given in > rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am > getting the following error . > Any suggestions to solve this issue. > I am using Solaris SPARC 64 bit machine. > > ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar > java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 > (Possible cause: architecture word > width mismatch) thrown while loading gnu.io.RXTXCommDriver > Exception in thread "main" java.lang.UnsatisfiedLinkError: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF > class: ELFCLASS64 (Possible cause: > architecture word width mismatch) > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(Unknown Source) > at java.lang.ClassLoader.loadLibrary(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > at com.ReadFromModem.main(ReadFromModem.java:84) > > * > * > > *Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > > > Oberhuber, Martin wrote: >> Sandeep, >> shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse >> variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on >> Sol7 but I've successfully run it on Sol9 and Sol10. >> Or is your request really about a native 64bit variant? I'm afraid that >> then >> you're out of luck since I think that quite a bit of RXTX is not yet ready >> for 64 bit. >> Cheers, >> -- >> *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> ------------------------------------------------------------------------ >> *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On >> Behalf Of *Sandeep Kumar K >> *Sent:* Tuesday, August 05, 2008 7:19 PM >> *To:* rxtx at qbang.org >> *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so >> for Solaris 9 >> >> Hi, >> >> Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 >> bit machine. The librxtxSerial.so given in website is for Solaris 8. >> >> *-- >> Thanks & Regards >> >> Sandeep Kumar K >> Sr. Software Engineer >> Geneva Software Technologies >> Whitefield, Bangalore >> Mob : 9880193454* >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> From michael.erskine at ketech.com Wed Aug 6 01:39:28 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 6 Aug 2008 08:39:28 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Florian Manschwetus wrote: > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) Hi Florian, I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. Regards, Michael Erskine. From florianmanschwetus at gmx.de Wed Aug 6 02:53:16 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 06 Aug 2008 10:53:16 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Message-ID: <4899667C.6010706@gmx.de> Michael Erskine schrieb: > Florian Manschwetus wrote: >> Ok, sounds fine for the receiving problem. >> But why i have to wait after each byte when sending a command squence? >> (the for loop in send command) > > Hi Florian, > I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. > > Regards, > Michael Erskine. > correct with a terminal on the other end it works, my idea was that this basic baud has some influence. Could some one explain what it is for? Florian > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/c2b4fa84/attachment-0034.bin From rick_knight at rlknight.com Wed Aug 6 13:01:07 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:01:07 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F4F3.3020707@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > I have an application (Readerware) that uses RXTX with Javax to access the serial port. This used to work fine under previous Linux' and Java, but something has changed, I assume with Java itself , that is causing the application to fail with a link error. The application is not able to find librxtxSerialParallel.so. RXTX supplies librxtxSerial.so and librxtxParallel.so, but not librxtxSerialParallel.so. Where can I get librxtxSerialParallel.so, or do I need it? Is something else causing the lib to not be found? Thanks, Rick Knight From rick_knight at rlknight.com Wed Aug 6 13:17:55 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:17:55 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F8E3.5060400@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Thanks for the reply. The developer of the app I'm trying to use (Readerware) has sent me a copy of the comm.api and I've copied the library (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar into the proper places. When I try to run the application, I get this error... Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: /usr/lib/libSolarisSerialParallel.so: /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not little-endian (Possible cause: endianness mismatch) Caught java.lang.UnsatisfiedLinkError: com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I while loading driver com.sun.comm.SolarisDriver Is there a way around this error? Thanks again, Rick Knight From jlar310 at gmail.com Wed Aug 6 13:37:42 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 14:37:42 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899F8E3.5060400@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > The developer of the app I'm trying to use (Readerware) has sent me a > copy of the comm.api and I've copied the library > (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar > into the proper places. When I try to run the application, I get this > error... > > Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: > /usr/lib/libSolarisSerialParallel.so: > /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not > little-endian (Possible cause: endianness mismatch) > Caught java.lang.UnsatisfiedLinkError: > com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I > > while loading driver com.sun.comm.SolarisDriver > > Is there a way around this error? What host OS are you running? From your original post it looks like 32 bit Linux. The libSolarisSerialParallel.so file is for Sun Solaris and will vary depending on the underlying hardware architecture as well. Sorry for the double post Rick, but I failed to send this to the list the first time... -- Jeff From rick_knight at rlknight.com Wed Aug 6 13:44:29 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:44:29 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: <4899FF1D.9030504@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > > >> The developer of the app I'm trying to use (Readerware) has sent me a >> copy of the comm.api and I've copied the library >> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >> into the proper places. When I try to run the application, I get this >> error... >> >> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >> /usr/lib/libSolarisSerialParallel.so: >> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >> little-endian (Possible cause: endianness mismatch) >> Caught java.lang.UnsatisfiedLinkError: >> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >> >> while loading driver com.sun.comm.SolarisDriver >> >> Is there a way around this error? >> > > What host OS are you running? From your original post it looks like 32 > bit Linux. > > The libSolarisSerialParallel.so file is for Sun Solaris and will vary > depending on the underlying hardware architecture as well. > > I'm running Kubuntu Linux (debian based). It's 32 bit. Rick Knight From jlar310 at gmail.com Wed Aug 6 15:33:23 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 16:33:23 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > I don't think Sun did binary libraries for Linux in the 2.0 version. Can someone with more historical experience than I confirm that? I recently tried to port a Comm API application from Solaris sparc to Linux x86 and likewise could not get my hands on the binary libraries. I eventually just re-wrote the code to use the gnu namespace packages and rxtx 2.1. What I don't understand is why your application vendor does not provide everything you need to run their software. FYI: I have librxtxParallel.so and librxtxSerial.so installed at JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is /usr/java/default which is actually a softlink to /usr/java/jre1.6.0_05. -- Jeff From defiantlew at yahoo.com.au Wed Aug 6 16:29:33 2008 From: defiantlew at yahoo.com.au (Lew L) Date: Thu, 7 Aug 2008 08:29:33 +1000 Subject: [Rxtx] Sun's Comm API Documentation References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> Message-ID: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> As a matter of interest is the Sun Comm API documentation available somewhere? I have tried the Sun site but it seems to have been removed. Unless I have missed the documentation for RXTX? I javadocced the RXTX source but information (to me) is minimal. Somewhere I got the impression that the Sun Comm API docs is, or was, compatible with RXTX, what is the best docs to use in conjuntion with RXTX and where may the be available? Cheers Lew From rick_knight at rlknight.com Wed Aug 6 17:18:33 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:18:33 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A3149.4050306@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff I'm not sure if I posted this here or not, but when I try to build RXTX from source I get this install error... make all-am make[1]: Entering directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' make[1]: Nothing to be done for `all-am'. make[1]: Leaving directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 Can you tell me how to get past this error and get RXTX built and installed? Thanks, Rick From bboyes at systronix.com Wed Aug 6 17:40:12 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Wed, 06 Aug 2008 17:40:12 -0600 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: At 16:29 08/06/2008, Lew L wrote: >As a matter of interest is the Sun Comm API documentation available >somewhere? I have tried the Sun site but it seems to have been removed. It's in the file we have posted, link in prev email (sorry, in a huge hurry right now). Javadocs definitely there. >Unless I have missed the documentation for RXTX? I javadocced the RXTX >source but information (to me) is minimal. >Somewhere I got the impression that the Sun Comm API docs is, or was, >compatible with RXTX, what is the best docs to use in conjuntion with RXTX >and where may the be available? Yeah, this is one of my concerns/beefs. There is little documentation for RXTX and it isn't just the same as javaxcomm. I would be willing to help out writing docs for RXTX! Yes really... esp if we can fix the Bluetooth issues. best regards Bruce >Cheers >Lew > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx ------- WWW.SYSTRONIX.COM ---------- Real embedded Java and much more +1-801-534-1017 Salt Lake City, USA From rick_knight at rlknight.com Wed Aug 6 17:54:08 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:54:08 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A39A0.2090309@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff, I would like for my vendor to switch to rxtx 2.1. It would make things much easier for me. I'm not sure why he's still using the javax compatible code. He's a small operation. Re-writing the code to use gnu namespace sounds like a major overhaul. Was it? Thanks, Rick From tjarvi at qbang.org Wed Aug 6 21:35:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:35:12 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: >> >>> Jeff wrote: >>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>>> >>>> >>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things > much easier for me. I'm not sure why he's still using the javax > compatible code. He's a small operation. Re-writing the code to use gnu > namespace sounds like a major overhaul. Was it? > Hi Jeff, The changes are fairly mechanical. Imports need to change and any explicite use of the namespace needs to change such as catching an exception. The following script was made for maintaining rxtx 2.0 but can apply to other needs. It is in the contrib dir with rxtx source. #!/bin/sh # Don't use! :) # # Sat, 03 May 2003 16:45:08 Modifications from J?rg Weule # Create a ed-cmd for the change of one pattern # case $1 in gnu) X=g/javax_comm/s+javax_comm+gnu_io+g ;; javax) X=g/gnu_io/s+gnu_io+javax_comm+g ;; *) echo;echo;echo From the top rxtx directory run;echo;echo -e \\t./ChangePackage.sh gnu;echo -e \\t\\tor;echo -e \\t./ChangePackage.sh javax;echo;echo; exit 0 ;; esac # # ed will be used to keep the owner and mode of the files unchanged. # We have run the ed-script for the characters '.' '/' as well. # "tr _ $D" do the change. # find . -type f -a -print | grep -v $0 | (while read F ; do ( echo $X; echo $X| tr _ /; echo $X| tr _ .; echo w; echo q ) | ed $F 2>&1 >/dev/null done ) # # Now we do little changes at the Makefiles. Hope that all we need. # find . -name Makefile\* -a -print | (while read F ; do cat < References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: On Thu, 7 Aug 2008, Lew L wrote: > As a matter of interest is the Sun Comm API documentation available > somewhere? I have tried the Sun site but it seems to have been removed. > > Unless I have missed the documentation for RXTX? I javadocced the RXTX > source but information (to me) is minimal. > Somewhere I got the impression that the Sun Comm API docs is, or was, > compatible with RXTX, what is the best docs to use in conjuntion with RXTX > and where may the be available? > Hi Lew, The documentation on Sun's website is accurate. The changes that are problematic in 3.0 are on the backside which rxtx used to plug into. http://java.sun.com/products/javacomm/reference/api/index.html CommPortIdentifier may have some minor differences (judging by the authors notes). -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Aug 6 21:46:08 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:46:08 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > If javax.comm.properties is properly installed and you are using a 2.0 version of Sun's commapi with rxtx 2.0, you should not see the library attempt to load libSolarisSerialParallel.so. Sun CommAPI 3.0 will not work with any version of rxtx as it is hard coded to use the shared library. See the INSTALL file with rxtx-2.0 source for more help with the properties file. -- Trent Jarvi tjarvi at qbang.org From jlar310 at gmail.com Thu Aug 7 06:32:06 2008 From: jlar310 at gmail.com (Jeff) Date: Thu, 7 Aug 2008 07:32:06 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > Jeff wrote: >> >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >> wrote: >> >>> >>> Jeff wrote: >>> >>>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>> wrote: >>>> >>>> >>>> >>>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things much > easier for me. I'm not sure why he's still using the javax compatible code. > He's a small operation. Re-writing the code to use gnu namespace sounds like > a major overhaul. Was it? I found it quite easy. In fact, in order to accommodate the transition, I actually separated all of the code that deals directly with the Comm API or RXTX into a helper class. The helper class was then coded to use reflection to determine which library was available and then instantiate the necessary objects. No direct imports of either library are used. The main application just needs to get it's hands on the IO streams and need not deal directly with the libraries. Other programs may not be so simple... But this doesn't really help you unless your vendor forks over the source code... -- Jeff From rick_knight at rlknight.com Thu Aug 7 09:47:12 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Thu, 07 Aug 2008 08:47:12 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: <489B1900.10108@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >>> wrote: >>> >>> >>>> Jeff wrote: >>>> >>>> >>>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>>> copy of the comm.api and I've copied the library >>>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>>> into the proper places. When I try to run the application, I get this >>>>>> error... >>>>>> >>>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>>> /usr/lib/libSolarisSerialParallel.so: >>>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>>> little-endian (Possible cause: endianness mismatch) >>>>>> Caught java.lang.UnsatisfiedLinkError: >>>>>> >>>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>>> >>>>>> while loading driver com.sun.comm.SolarisDriver >>>>>> >>>>>> Is there a way around this error? >>>>>> >>>>>> >>>>>> >>>>> What host OS are you running? From your original post it looks like 32 >>>>> bit Linux. >>>>> >>>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>>> depending on the underlying hardware architecture as well. >>>>> >>>>> >>>>> >>>>> >>>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>>> >>>> >>>> >>> I don't think Sun did binary libraries for Linux in the 2.0 version. >>> Can someone with more historical experience than I confirm that? >>> >>> I recently tried to port a Comm API application from Solaris sparc to >>> Linux x86 and likewise could not get my hands on the binary libraries. >>> I eventually just re-wrote the code to use the gnu namespace packages >>> and rxtx 2.1. >>> >>> What I don't understand is why your application vendor does not >>> provide everything you need to run their software. >>> >>> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >>> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >>> /usr/java/default which is actually a softlink to >>> /usr/java/jre1.6.0_05. >>> >>> >>> >> Jeff, >> >> I would like for my vendor to switch to rxtx 2.1. It would make things much >> easier for me. I'm not sure why he's still using the javax compatible code. >> He's a small operation. Re-writing the code to use gnu namespace sounds like >> a major overhaul. Was it? >> > > I found it quite easy. In fact, in order to accommodate the > transition, I actually separated all of the code that deals directly > with the Comm API or RXTX into a helper class. The helper class was > then coded to use reflection to determine which library was available > and then instantiate the necessary objects. No direct imports of > either library are used. The main application just needs to get it's > hands on the IO streams and need not deal directly with the libraries. > Other programs may not be so simple... > > But this doesn't really help you unless your vendor forks over the > source code... > > Jeff, This may not help me directly, but I'm going to forward this thread to the vendor. I think he'll be open to making things work. Thanks again, Rick Knight From agusmunioz at gmail.com Thu Aug 7 16:39:51 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Thu, 7 Aug 2008 19:39:51 -0300 Subject: [Rxtx] How to send ack? Message-ID: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Hi, I'm still learning about serial communication and I have some doubts. I've got this question about how to do the following thing in rxtx. I have this hardware that connect to a PC using a serial port. These hardware receives data from a telephone line, proccess it, and then send it forward to the serial port. I've used a program named wincomm that shows what information is send it through the serial port and I have the nex behaviour: The hardware has a buffer where all data is stored, that cannot be sent it through the seria port. The program reads the first data send it by the hardware, and keep reading the same data always. There is a button in the application that says enable Ack, and when I click, then the hardware start to send all the stored information, and all the information is shown. I write a class, using rxtx that reads the serial port, and the same thing happens, it remains reading the same (first) data all the time. And I thing something like the enable Ack I'm missing. How can I do this enable Ack from my java code using rxtx? Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080807/e0a0f9a1/attachment-0032.html From ajmas at sympatico.ca Thu Aug 7 18:26:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 7 Aug 2008 20:26:41 -0400 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: <4BF42297-81E2-4BB8-A89F-1D43588379AE@sympatico.ca> On 6-Aug-08, at 19:40 , Bruce Boyes wrote: >> Unless I have missed the documentation for RXTX? I javadocced the >> RXTX >> source but information (to me) is minimal. >> Somewhere I got the impression that the Sun Comm API docs is, or was, >> compatible with RXTX, what is the best docs to use in conjuntion >> with RXTX >> and where may the be available? > > Yeah, this is one of my concerns/beefs. There is little documentation > for RXTX and it isn't just the same as javaxcomm. > > I would be willing to help out writing docs for RXTX! Yes really... > esp if we can fix the Bluetooth issues. If you want to contribute documentation then the best place to do that is the wiki. If there is anything missing or that could be improved on then please do so. If there are any points that you would like to see improved, for which you don't have the knowledge then ask on the mailing list for a volunteer. Andre From florianmanschwetus at gmx.de Fri Aug 8 03:04:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Fri, 08 Aug 2008 11:04:14 +0200 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Message-ID: <489C0C0E.2020401@gmx.de> Agustin Mu?oz schrieb: > Hi, I'm still learning about serial communication and I have some > doubts. I've got this question about how to do the following thing in rxtx. > I have this hardware that connect to a PC using a serial port. These > hardware receives data from a telephone line, proccess it, and then send > it forward to the serial port. I've used a program named wincomm that > shows what information is send it through the serial port and I have the > nex behaviour: > > The hardware has a buffer where all data is stored, that cannot be sent > it through the seria port. > The program reads the first data send it by the hardware, and keep > reading the same data always. > There is a button in the application that says enable Ack, and when I > click, then the hardware start to send all the stored information, and > all the information is shown. > > I write a class, using rxtx that reads the serial port, and the same > thing happens, it remains reading the same (first) data all the time. > And I thing something like the enable Ack I'm missing. > How can I do this enable Ack from my java code using rxtx? Afaik, a look at man ascii reveals: Okt Dez Hex Char 006 6 06 ACK So, i hope this will do the job: send(6); florian > > Thanks in advance > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/5b4965f8/attachment-0032.bin From agusmunioz at gmail.com Fri Aug 8 16:31:00 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 19:31:00 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <489C0C0E.2020401@gmx.de> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> Message-ID: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Hi Florian, thanks for the answer. By send(6) you mean to get the port OutputStream and write a 6? I try that but it didn't work. Any suggestion? Thanks On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < florianmanschwetus at gmx.de> wrote: > Agustin Mu?oz schrieb: > > Hi, I'm still learning about serial communication and I have some doubts. >> I've got this question about how to do the following thing in rxtx. >> I have this hardware that connect to a PC using a serial port. These >> hardware receives data from a telephone line, proccess it, and then send it >> forward to the serial port. I've used a program named wincomm that shows >> what information is send it through the serial port and I have the nex >> behaviour: >> >> The hardware has a buffer where all data is stored, that cannot be sent >> it through the seria port. >> The program reads the first data send it by the hardware, and keep reading >> the same data always. >> There is a button in the application that says enable Ack, and when I >> click, then the hardware start to send all the stored information, and all >> the information is shown. >> >> I write a class, using rxtx that reads the serial port, and the same thing >> happens, it remains reading the same (first) data all the time. And I thing >> something like the enable Ack I'm missing. >> How can I do this enable Ack from my java code using rxtx? >> > Afaik, a look at man ascii reveals: > Okt Dez Hex Char > 006 6 06 ACK > So, i hope this will do the job: > send(6); > > florian > >> >> Thanks in advance >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/7f3fba42/attachment-0031.html From agusmunioz at gmail.com Fri Aug 8 18:39:27 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 21:39:27 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Message-ID: <988288430808081739x7f9e7889id82591d5a9e2b4f6@mail.gmail.com> Ok, Florian, it works!! my problem was that I've been sending, through the OutputStream, the bytes of 6 as a string: out.write("6".getBytes()); but then I realized that you can write an int on an OuptuStream, so I tried that and It works: out.write(6); Thank you for the guidance!! On Fri, Aug 8, 2008 at 7:31 PM, Agustin Mu?oz wrote: > Hi Florian, thanks for the answer. By send(6) you mean to get the port > OutputStream and write a 6? > > I try that but it didn't work. > > Any suggestion? > > Thanks > > > On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < > florianmanschwetus at gmx.de> wrote: > >> Agustin Mu?oz schrieb: >> >> Hi, I'm still learning about serial communication and I have some doubts. >>> I've got this question about how to do the following thing in rxtx. >>> I have this hardware that connect to a PC using a serial port. These >>> hardware receives data from a telephone line, proccess it, and then send it >>> forward to the serial port. I've used a program named wincomm that shows >>> what information is send it through the serial port and I have the nex >>> behaviour: >>> >>> The hardware has a buffer where all data is stored, that cannot be sent >>> it through the seria port. >>> The program reads the first data send it by the hardware, and keep >>> reading the same data always. >>> There is a button in the application that says enable Ack, and when I >>> click, then the hardware start to send all the stored information, and all >>> the information is shown. >>> >>> I write a class, using rxtx that reads the serial port, and the same >>> thing happens, it remains reading the same (first) data all the time. And I >>> thing something like the enable Ack I'm missing. >>> How can I do this enable Ack from my java code using rxtx? >>> >> Afaik, a look at man ascii reveals: >> Okt Dez Hex Char >> 006 6 06 ACK >> So, i hope this will do the job: >> send(6); >> >> florian >> >>> >>> Thanks in advance >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/b918ab3d/attachment-0031.html From florianmanschwetus at gmx.de Sat Aug 9 00:45:43 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Sat, 09 Aug 2008 08:45:43 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4899667C.6010706@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> Message-ID: <489D3D17.9090209@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >> Florian Manschwetus wrote: >>> Ok, sounds fine for the receiving problem. >>> But why i have to wait after each byte when sending a command squence? >>> (the for loop in send command) >> >> Hi Florian, >> I'd imagine you probably don't! You could send all bytes in one go and >> RXTX would send them. The problem is most probably the other end: >> perhaps it has a really small buffer, some non-standard UART, or a >> crazy timing issue. If you attach a terminal to your output and send >> all the bytes of a command in one go they should appear no problem. >> >> Regards, >> Michael Erskine. >> > correct with a terminal on the other end it works, my idea was that this > basic baud has some influence. Could some one explain what it is for? > > Florian To make it more clear, my problem is that i can't use: outputStream.write(byte[]); => Beamer doesn't understand the sequence. (mostly no answer when he answers then *001) when i use this construct instead: for (int i = 0; i < command.length; i++) { this.outputStream.write(command[i]); try { Thread.sleep(25); } catch (InterruptedException e) { // TODO Auto-generated catch block e.printStackTrace(); } } it works nearly reliable. So what could it be? This Basic Baud is what exactly? Florian -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080809/692304ee/attachment-0031.bin From tjarvi at qbang.org Sat Aug 9 16:37:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Aug 2008 16:37:19 -0600 (MDT) Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489D3D17.9090209@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> <489D3D17.9090209@gmx.de> Message-ID: On Sat, 9 Aug 2008, Florian Manschwetus wrote: > Florian Manschwetus schrieb: >> Michael Erskine schrieb: >>> Florian Manschwetus wrote: >>>> Ok, sounds fine for the receiving problem. >>>> But why i have to wait after each byte when sending a command squence? >>>> (the for loop in send command) >>> >>> Hi Florian, >>> I'd imagine you probably don't! You could send all bytes in one go and >>> RXTX would send them. The problem is most probably the other end: perhaps >>> it has a really small buffer, some non-standard UART, or a crazy timing >>> issue. If you attach a terminal to your output and send all the bytes of a >>> command in one go they should appear no problem. >>> >>> Regards, >>> Michael Erskine. >>> >> correct with a terminal on the other end it works, my idea was that this >> basic baud has some influence. Could some one explain what it is for? >> >> Florian > To make it more clear, > my problem is that i can't use: > outputStream.write(byte[]); > => Beamer doesn't understand the sequence. (mostly no answer when he answers > then *001) > > when i use this construct instead: > > for (int i = 0; i < command.length; i++) { > this.outputStream.write(command[i]); > try { > Thread.sleep(25); > } catch (InterruptedException e) { > // TODO Auto-generated catch block > e.printStackTrace(); > } > } > > it works nearly reliable. > > So what could it be? This Basic Baud is what exactly? > I suspect you are using the 'moon protocol' and don't know it. RXTX enables this by default. The buffer on the other end is first in first out while reading. If the buffer is full, the bits are hand carried to the moon and burried. Then if the other side reads a couple bytes, two more bytes go into the buffer followed by more moon protocol. The resulting array of bytes the other side reads may appear to be scrambled until you go to the moon, get the bits and insert them in the right place. Flow control can prevent the default moon protocol and throttles the communiation by almost writing a byte at a time as need be. Hardware flow control is preferable but software flow control should also work. Read and write can appear to hang if the other side is not connected. This is why we don't enable them all the time. If you can't use flow control, you have to take care with the moon protocol and give the other side time to read. That is what your slower version of write is doing. -- Trent Jarvi tjarvi at qbang.org From rxtx at allenjb.me.uk Mon Aug 11 08:06:36 2008 From: rxtx at allenjb.me.uk (AllenJB) Date: Mon, 11 Aug 2008 15:06:36 +0100 Subject: [Rxtx] Disabling EV_RXFLAG Message-ID: <48A0476C.2090800@allenjb.me.uk> Hi all, I'm working with a device which does not use an EvtChar and need to disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an event mask of FD 01 00 00. The reference software I have uses FB 00 00 00. With the rxtx mask I get framing errors which I believe are caused when the EvtChar is received. Is there currently a way with rxtx (I've using rxtx from Java) to disable EV_RXFLAG? If not from Java, where would I start if I wanted to turn the EV_RXFLAG option off in the C code? I've had a grep of the rxtx source code, but I can't see where EV_RXFLAG is being set. Thanks in advance, AllenJB From tjarvi at qbang.org Mon Aug 11 14:17:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Aug 2008 14:17:27 -0600 (MDT) Subject: [Rxtx] Disabling EV_RXFLAG In-Reply-To: <48A0476C.2090800@allenjb.me.uk> References: <48A0476C.2090800@allenjb.me.uk> Message-ID: On Mon, 11 Aug 2008, AllenJB wrote: > Hi all, > > I'm working with a device which does not use an EvtChar and need to > disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an > event mask of FD 01 00 00. The reference software I have uses FB 00 00 > 00. With the rxtx mask I get framing errors which I believe are caused > when the EvtChar is received. > > Is there currently a way with rxtx (I've using rxtx from Java) to > disable EV_RXFLAG? > > If not from Java, where would I start if I wanted to turn the EV_RXFLAG > option off in the C code? I've had a grep of the rxtx source code, but I > can't see where EV_RXFLAG is being set. > > Thanks in advance, > > AllenJB Hi Allen, I'd look at termios.c::tcsetattr() and termios.c::FillDCB() -- Trent Jarvi tjarvi at qbang.org From superdadusa at gmail.com Tue Aug 12 13:57:32 2008 From: superdadusa at gmail.com (John Choi) Date: Tue, 12 Aug 2008 13:57:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. Message-ID: Hi all, Just let you all know I just start to learn Java. I have download the serial comm package and the source code from open source communities.. I was able to verify with the given message string via serial monitor. when the given message string sends to the serial port then the character return added to the end of string by default if I use "Hello World" however if I changed to something else other than "Hello, World" there is no character return add to the end of string. I thing the library download from rxtx.org has implemented for the special strings. I can do like "login\n" in the string message to make character return but I don't want to add this individual custom character for each command return in every static message string I send, Can any who have done this might help me? Basically, something like this,, Write and add function to the program write a command, Reads the respond from a serial device.. Function handles multiple messages, Write: "com open" Read: Welcome to my world" expected Write: "admin" Read: Password?, expected Write: "admin" Read: you are successfully login terminal, expected. And I need to add a separate function handler handles a character return add to the each command above. If anyone can help this I can do the reset? Thank you in advance, John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0027.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SerialIO.java Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0027.pl From Steffen.DETTMER at ingenico.com Wed Aug 13 02:16:38 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 13 Aug 2008 10:16:38 +0200 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: References: Message-ID: <20080813081638.GA25412@elberon.bln.de.ingenico.com> * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > I can do like "login\n" in the string message to make character > return but I don't want to add this individual custom character > for each command return in every static message string I send, and why not?! > Can any who have done this might help me? what's about with writing a small wrapper function adding the carriage return? However, this would be slow, because either you call write two times (very bad) or the string needs to be copied, \n appended and written (since you are using Java Performance probably isn't so critical). Personally I would write `"login\n"' and `username + "\n"' etc., because since it is part of the command it should be part of the command definition string. > Basically, something like this,, Write and add function to the program write > a command, Reads the respond from a serial device.. correctly reading a `line' is more difficult. If you cannot make assumptions about timeouts and/or you need to have low delay, you need to read byte wise. If you need to save CPU resources you might need to add some buffering layer that you can read byte-wise but that is reading blockwise with some small timeout (lets say for serial lines something around byte transmission time times three or so). > /* > * To change this template, choose Tools | Templates > * and open the template in the editor. > */ :) > package joliba; > > /** > * > * @author root > */ :) > // derived from SUN's examples in the javax.comm package > import java.io.*; > import java.util.*; > //import javax.comm.*; // for SUN's serial/parallel port libraries > import gnu.io.*; // for rxtxSerial library > > public class SerialIO implements Runnable, SerialPortEventListener { > static CommPortIdentifier portId; > static CommPortIdentifier saveportId; > static Enumeration portList; > InputStream inputStream; > SerialPort serialPort; > Thread readThread; You need a thread for your synchronous RPC-style protocol? > static String messageString = "Hello, world!"; > static OutputStream outputStream; > static boolean outputBufferEmptyFlag = false; > > public static void main(String[] args) { > boolean portFound = false; > String defaultPort; > > // determine the name of the serial port on several operating systems > String osname = System.getProperty("os.name","").toLowerCase(); > if ( osname.startsWith("windows") ) { > // windows > defaultPort = "COM1"; > } else if (osname.startsWith("linux")) { > // linux > defaultPort = "/dev/ttyS0"; > } else if ( osname.startsWith("mac") ) { > // mac > defaultPort = "????"; > } else { > System.out.println("Sorry, your operating system is not supported"); > return; > } Is such a construction recommended? Isn't there some abstraction (like COM1 working on any platform)? [...] > try { > // activate the OUTPUT_BUFFER_EMPTY notifier > serialPort.notifyOnOutputEmpty(true); > } catch (Exception e) { > System.out.println("Error setting event notification"); > System.out.println(e.toString()); > System.exit(-1); > } I doubt that -1 is defined, probably some 127 or so would be the result, maybe better simply `throw e'? > public void writetoport() { > System.out.println("Writing \""+messageString+"\" to "+serialPort.getName()); > try { > // write string to serial port > outputStream.write(messageString.getBytes()); > } catch (IOException e) {} > } maybe something like /** * Writes the given output string and an additional carriage * return to the current outputStream. */ public void writeStringToPort( /** The output string (without CR). */ String output ) throws IOException { String outputLine = output + "\n"; outputStream.write(outputLine.getBytes()); } ? > > public SerialIO() { > // initalize serial port > try { > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > } catch (PortInUseException e) {} if the port is in use, you continue? Wonder that this works in Java, I would assume serialPort beeing uninitialized which AFAIK is an error in Java. > try { > inputStream = serialPort.getInputStream(); > } catch (IOException e) {} > > try { > serialPort.addEventListener(this); > } catch (TooManyListenersException e) {} > > // activate the DATA_AVAILABLE notifier > serialPort.notifyOnDataAvailable(true); > > try { > // set port parameters > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > } catch (UnsupportedCommOperationException e) {} > > // start the read thread > readThread = new Thread(this); > readThread.start(); > > } I think in all those exception cases you can abort, because it is unlikely that ignoring those errors allow a successful continuation, so in this case maybe it would be better to add a throw clause to the method. > public void run() { > // first thing in the thread, we initialize the write operation > initwritetoport(); > try { > while (true) { > // write string to port, the serialEvent will read it > writetoport(); > Thread.sleep(1000); > } > } catch (InterruptedException e) {} > } Does this make sense? Your `SimpleReadApp' writes one and the same string each second? > public void serialEvent(SerialPortEvent event) { > switch (event.getEventType()) { > case SerialPortEvent.BI: > case SerialPortEvent.OE: > case SerialPortEvent.FE: > case SerialPortEvent.PE: > case SerialPortEvent.CD: > case SerialPortEvent.CTS: > case SerialPortEvent.DSR: > case SerialPortEvent.RI: > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > break; > case SerialPortEvent.DATA_AVAILABLE: > // we get here if data has been received > byte[] readBuffer = new byte[20]; > try { > // read data > while (inputStream.available() > 0) { > int numBytes = inputStream.read(readBuffer); > } > // print data > String result = new String(readBuffer); > System.out.println("Read: "+result); > } catch (IOException e) {} I doubt that this is correct. I would assume you will get a 20 bytes result always, if more bytes would be available they would be printed in a second line but if less bytes are read I'd assume that the buffer/result contains zero bytes from implicite readBuffer contents initialisation (zero is no string terminator in Java AFAIK). > break; > } > } > } oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From florianmanschwetus at gmx.de Wed Aug 13 06:09:31 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 13 Aug 2008 14:09:31 +0200 Subject: [Rxtx] someone has seen such errors? Message-ID: <48A2CEFB.90007@gmx.de> I mean my communication mostly works, but it is far from perfect could this be the reason? Florian Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/949b9947/attachment-0027.bin From superdadusa at gmail.com Wed Aug 13 08:40:32 2008 From: superdadusa at gmail.com (John Choi) Date: Wed, 13 Aug 2008 08:40:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: <20080813081638.GA25412@elberon.bln.de.ingenico.com> References: <20080813081638.GA25412@elberon.bln.de.ingenico.com> Message-ID: Thank you so much Steffen and I will try that suggestion. John On 8/13/08, Steffen DETTMER wrote: > > * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > > I can do like "login\n" in the string message to make character > > return but I don't want to add this individual custom character > > for each command return in every static message string I send, > > and why not?! > > > Can any who have done this might help me? > > what's about with writing a small wrapper function adding the > carriage return? > However, this would be slow, because either you call write two > times (very bad) or the string needs to be copied, \n appended > and written (since you are using Java Performance probably isn't > so critical). > > Personally I would write `"login\n"' and `username + "\n"' etc., > because since it is part of the command it should be part of the > command definition string. > > > Basically, something like this,, Write and add function to the program > write > > a command, Reads the respond from a serial device.. > > correctly reading a `line' is more difficult. If you cannot make > assumptions about timeouts and/or you need to have low delay, you > need to read byte wise. If you need to save CPU resources you > might need to add some buffering layer that you can read > byte-wise but that is reading blockwise with some small timeout > (lets say for serial lines something around byte transmission > time times three or so). > > > /* > > * To change this template, choose Tools | Templates > > * and open the template in the editor. > > */ > > :) > > > package joliba; > > > > /** > > * > > * @author root > > */ > > :) > > > // derived from SUN's examples in the javax.comm package > > import java.io.*; > > import java.util.*; > > //import javax.comm.*; // for SUN's serial/parallel port libraries > > import gnu.io.*; // for rxtxSerial library > > > > public class SerialIO implements Runnable, SerialPortEventListener { > > static CommPortIdentifier portId; > > static CommPortIdentifier saveportId; > > static Enumeration portList; > > InputStream inputStream; > > SerialPort serialPort; > > Thread readThread; > > You need a thread for your synchronous RPC-style protocol? > > > static String messageString = "Hello, world!"; > > static OutputStream outputStream; > > static boolean outputBufferEmptyFlag = false; > > > > public static void main(String[] args) { > > boolean portFound = false; > > String defaultPort; > > > > // determine the name of the serial port on several operating > systems > > String osname = System.getProperty("os.name","").toLowerCase(); > > if ( osname.startsWith("windows") ) { > > // windows > > defaultPort = "COM1"; > > } else if (osname.startsWith("linux")) { > > // linux > > defaultPort = "/dev/ttyS0"; > > } else if ( osname.startsWith("mac") ) { > > // mac > > defaultPort = "????"; > > } else { > > System.out.println("Sorry, your operating system is not > supported"); > > return; > > } > > Is such a construction recommended? Isn't there some abstraction > (like COM1 working on any platform)? > > [...] > > try { > > // activate the OUTPUT_BUFFER_EMPTY notifier > > serialPort.notifyOnOutputEmpty(true); > > } catch (Exception e) { > > System.out.println("Error setting event notification"); > > System.out.println(e.toString()); > > System.exit(-1); > > } > > I doubt that -1 is defined, probably some 127 or so would be the > result, maybe better simply `throw e'? > > > public void writetoport() { > > System.out.println("Writing \""+messageString+"\" to > "+serialPort.getName()); > > try { > > // write string to serial port > > outputStream.write(messageString.getBytes()); > > } catch (IOException e) {} > > } > > maybe something like > > /** > * Writes the given output string and an additional carriage > * return to the current outputStream. > */ > public void > writeStringToPort( > /** The output string (without CR). */ > String output > ) throws IOException > { > String outputLine = output + "\n"; > outputStream.write(outputLine.getBytes()); > } > > ? > > > > > public SerialIO() { > > // initalize serial port > > try { > > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > > } catch (PortInUseException e) {} > > if the port is in use, you continue? Wonder that this works in > Java, I would assume serialPort beeing uninitialized which AFAIK > is an error in Java. > > > try { > > inputStream = serialPort.getInputStream(); > > } catch (IOException e) {} > > > > try { > > serialPort.addEventListener(this); > > } catch (TooManyListenersException e) {} > > > > // activate the DATA_AVAILABLE notifier > > serialPort.notifyOnDataAvailable(true); > > > > try { > > // set port parameters > > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > } catch (UnsupportedCommOperationException e) {} > > > > // start the read thread > > readThread = new Thread(this); > > readThread.start(); > > > > } > > I think in all those exception cases you can abort, because it is > unlikely that ignoring those errors allow a successful > continuation, so in this case maybe it would be better to add a > throw clause to the method. > > > public void run() { > > // first thing in the thread, we initialize the write operation > > initwritetoport(); > > try { > > while (true) { > > // write string to port, the serialEvent will read it > > writetoport(); > > Thread.sleep(1000); > > } > > } catch (InterruptedException e) {} > > } > > Does this make sense? Your `SimpleReadApp' writes one and the > same string each second? > > > public void serialEvent(SerialPortEvent event) { > > switch (event.getEventType()) { > > case SerialPortEvent.BI: > > case SerialPortEvent.OE: > > case SerialPortEvent.FE: > > case SerialPortEvent.PE: > > case SerialPortEvent.CD: > > case SerialPortEvent.CTS: > > case SerialPortEvent.DSR: > > case SerialPortEvent.RI: > > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > > break; > > case SerialPortEvent.DATA_AVAILABLE: > > // we get here if data has been received > > byte[] readBuffer = new byte[20]; > > try { > > // read data > > while (inputStream.available() > 0) { > > int numBytes = inputStream.read(readBuffer); > > } > > // print data > > String result = new String(readBuffer); > > System.out.println("Read: "+result); > > } catch (IOException e) {} > > I doubt that this is correct. I would assume you will get a 20 > bytes result always, if more bytes would be available they would > be printed in a second line but if less bytes are read I'd assume > that the buffer/result contains zero bytes from implicite > readBuffer contents initialisation (zero is no string terminator > in Java AFAIK). > > > break; > > } > > } > > } > > oki, > > Steffen > > About Ingenico Throughout the world businesses rely on Ingenico for secure > and expedient electronic transaction acceptance. Ingenico products leverage > proven technology, established standards and unparalleled ergonomics to > provide optimal reliability, versatility and usability. This comprehensive > range of products is complemented by a global array of services and > partnerships, enabling businesses in a number of vertical sectors to accept > transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged > information. If you are not the addressee or authorized to receive this for > the addressee, you must not use, copy, disclose or take any action based on > this message or any information herein. If you have received this message in > error, please advise the sender immediately by reply e-mail and delete this > message. Thank you for your cooperation. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/73c4135c/attachment-0026.html From ajmas at sympatico.ca Sat Aug 16 07:15:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 09:15:41 -0400 Subject: [Rxtx] someone has seen such errors? In-Reply-To: <48A2CEFB.90007@gmx.de> References: <48A2CEFB.90007@gmx.de> Message-ID: <43B5E8DA-1D93-4D90-809B-AAF35FF724C5@sympatico.ca> On 13-Aug-08, at 08:09 , Florian Manschwetus wrote: > I mean my communication mostly works, but it is far from perfect > could this be the reason? > > Florian > > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control Judging by the error messages this looks related to the driver you are using. Do a search for the following string with you favourite search engine, it should turn up a few hits: ftdi_set_termios FAILED to set databits/stopbits/parity Andre From ajmas at sympatico.ca Sat Aug 16 19:12:04 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 21:12:04 -0400 Subject: [Rxtx] Using SerialPortEvent? Message-ID: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Hi, Could someone tell me how I should be using the SerialPortEvent? Am I meant to be waiting for data and then simply reading from the inputstream? If this is the case why no just block on an inputstream read? Andr? From tjarvi at qbang.org Sat Aug 16 19:41:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 16 Aug 2008 19:41:13 -0600 (MDT) Subject: [Rxtx] Using SerialPortEvent? In-Reply-To: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> References: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Message-ID: On Sat, 16 Aug 2008, Andre-John Mas wrote: > Hi, > > Could someone tell me how I should be using the SerialPortEvent? Am I > meant to be waiting for data and then simply reading from the > inputstream? If this is the case why no just block on an inputstream > read? > Polling for data is fine also. It really depends upon what you are trying to do. For instance, if you require x bytes before reading, you can start polling after data is available. If you read on the same thread as your GUI and are waiting for data in a read, the results may be less than desirable. Java programming is 'usually' event driven rather than polling based. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sat Aug 16 20:10:39 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 22:10:39 -0400 Subject: [Rxtx] Using SerialPortEvent? In-Reply-To: References: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Message-ID: <3E495D4C-BB28-4845-A6AB-984C9A826BDF@sympatico.ca> On 16-Aug-08, at 21:41 , Trent Jarvi wrote: > On Sat, 16 Aug 2008, Andre-John Mas wrote: > >> Hi, >> >> Could someone tell me how I should be using the SerialPortEvent? Am I >> meant to be waiting for data and then simply reading from the >> inputstream? If this is the case why no just block on an inputstream >> read? >> > > Polling for data is fine also. It really depends upon what you are > trying to do. For instance, if you require x bytes before reading, > you can start polling after data is available. If you read on the > same thread as your GUI and are waiting for data in a read, the > results may be less than desirable. > > Java programming is 'usually' event driven rather than polling based. Sounds good. I thought I would use this opportunity to provide a event based version of the TwoWaySerialComm example. Could you just validate it before I add it to the Wiki: package ajmas74.experimental; import gnu.io.CommPort; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; import gnu.io.SerialPortEvent; import gnu.io.SerialPortEventListener; import java.io.IOException; import java.io.InputStream; import java.io.OutputStream; /** * This version of the TwoWaySerialComm example makes use of the * SerialPortEventListener to avoid polling. * * @author ajmas * */ public class TwoWaySerialComm { public TwoWaySerialComm() { super(); } void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { CommPort commPort = portIdentifier.open(this.getClass().getName(),2000); if ( commPort instanceof SerialPort ) { SerialPort serialPort = (SerialPort) commPort; serialPort .setSerialPortParams (57600 ,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); (new Thread(new SerialWriter(out))).start(); serialPort.addEventListener(new SerialReader(in)); } else { System.out.println("Error: Only serial ports are handled by this example."); } } } /** * Handles the input coming from the serial port. A new line character * is treated as the end of a block in this example. */ public static class SerialReader implements SerialPortEventListener { private InputStream in; private byte[] buffer = new byte[1024]; public SerialReader ( InputStream in ) { this.in = in; } public void serialEvent(SerialPortEvent arg0) { int data; try { int len = 0; while ( ( data = in.read()) > -1 ) { if ( data != '\n' ) { break; } buffer[len++] = (byte) data; } System.out.print(new String(buffer,0,len)); } catch ( IOException e ) { e.printStackTrace(); System.exit(-1); } } } /** */ public static class SerialWriter implements Runnable { OutputStream out; public SerialWriter ( OutputStream out ) { this.out = out; } public void run () { try { int c = 0; while ( ( c = System.in.read()) > -1 ) { this.out.write(c); } } catch ( IOException e ) { e.printStackTrace(); System.exit(-1); } } } public static void main ( String[] args ) { try { (new TwoWaySerialComm()).connect("COM3"); } catch ( Exception e ) { e.printStackTrace(); } } } From lfarkas at lfarkas.org Tue Aug 19 07:32:59 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Tue, 19 Aug 2008 15:32:59 +0200 Subject: [Rxtx] JNI or CNI Message-ID: <48AACB8B.9060606@lfarkas.org> hi, what is the current recommended way to rxtx on linux JNI or it's better to use CNI? is the CNI version fully functional and the same level as the JNI? i currently try to make a rhel/centos/fedora rpm for rxtx but has many problems with the standard dir structure. yours. -- Levente "Si vis pacem para bellum!" From lfarkas at lfarkas.org Tue Aug 19 08:47:34 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Tue, 19 Aug 2008 16:47:34 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel Message-ID: <48AADD06.7040809@lfarkas.org> hi, newer or not so newer linux kernel do not contain the UTS_RELEASE so the current rxtx is not compile on the latest kernels. even if it's commented out in the cvs configure there are other places. i attcahed a patch which fix it (or at least doesn't cause error at non-debug build). ps. is there any plan to the new 2.1-8 release in the near future? there are many changes (at least the license change in all file and in this case create a diff is very difficult)? the latest release more then 2 years old:-( -- Levente "Si vis pacem para bellum!" -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-2.1-uts.patch Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080819/ab5d38ac/attachment-0020.pl From ajmas at sympatico.ca Tue Aug 19 16:21:53 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 19 Aug 2008 18:21:53 -0400 Subject: [Rxtx] Event based example Message-ID: <24735BFB-B088-4B84-8173-FE98DF63B12F@sympatico.ca> Hi, I have just posted an example of using SerialPortEventListener in the Wiki: http://rxtx.qbang.org/wiki/index.php/Event_Based_Two_Way_Communication If you see any issues please could you let me know, or makes the changes. Andre From Martin.Oberhuber at windriver.com Fri Aug 22 04:02:24 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 22 Aug 2008 12:02:24 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <48AADD06.7040809@lfarkas.org> References: <48AADD06.7040809@lfarkas.org> Message-ID: <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> Farkas, there are indeed efforts to get a new RXTX release out the door. Your experience as a package maintainer would likely be helpful during these efforts, since I'd think it makes sense to keep the patches minimal that you must make to have the source compile in your environment. What are the things that you find problematic, apart from the UTS thing that you have mentioned before? What is the timing that you have in mind for your package? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Farkas Levente > Sent: Tuesday, August 19, 2008 4:48 PM > To: rxtx at qbang.org > Subject: [Rxtx] UTS_RELEASE not defined in newer kernel > > hi, > newer or not so newer linux kernel do not contain the > UTS_RELEASE so the > current rxtx is not compile on the latest kernels. even if it's > commented out in the cvs configure there are other places. > i attcahed a patch which fix it (or at least doesn't cause error at > non-debug build). > > ps. is there any plan to the new 2.1-8 release in the near > future? there > are many changes (at least the license change in all file and in this > case create a diff is very difficult)? the latest release more then 2 > years old:-( > > -- > Levente "Si vis pacem para bellum!" > From lfarkas at lfarkas.org Fri Aug 22 04:36:26 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Fri, 22 Aug 2008 12:36:26 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> References: <48AADD06.7040809@lfarkas.org> <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> Message-ID: <48AE96AA.6090505@lfarkas.org> hi, the packages already build for fedora-9 and centos-5 and here: http://www.lfarkas.org/linux/packages/ what i've to patch, the UTS, the configure script, but it's already fixed in the cvs (in another way) and the loadlibrary. the reasons for last one can be found here: https://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_files_that_use_JNI after we test it i'd like to add these packages to fedora and epel main repository (that's why it's be useful a new release after 2 years:-) imho versions are cheap and why not just release 2.1-8? the real code changes are minimal and if something critical bug found still can release 2.1-9:-) ps. and would be better to use simple number for version like 2.1-7 rather then 2.1-7v2. Oberhuber, Martin wrote: > Farkas, > > there are indeed efforts to get a new RXTX release out the > door. Your experience as a package maintainer would likely > be helpful during these efforts, since I'd think it makes > sense to keep the patches minimal that you must make to > have the source compile in your environment. > > What are the things that you find problematic, apart from > the UTS thing that you have mentioned before? > > What is the timing that you have in mind for your package? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >> On Behalf Of Farkas Levente >> Sent: Tuesday, August 19, 2008 4:48 PM >> To: rxtx at qbang.org >> Subject: [Rxtx] UTS_RELEASE not defined in newer kernel >> >> hi, >> newer or not so newer linux kernel do not contain the >> UTS_RELEASE so the >> current rxtx is not compile on the latest kernels. even if it's >> commented out in the cvs configure there are other places. >> i attcahed a patch which fix it (or at least doesn't cause error at >> non-debug build). >> >> ps. is there any plan to the new 2.1-8 release in the near >> future? there >> are many changes (at least the license change in all file and in this >> case create a diff is very difficult)? the latest release more then 2 >> years old:-( >> >> -- >> Levente "Si vis pacem para bellum!" >> -- Levente "Si vis pacem para bellum!" From tjarvi at qbang.org Fri Aug 22 18:50:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Aug 2008 18:50:32 -0600 (MDT) Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <48AE96AA.6090505@lfarkas.org> References: <48AADD06.7040809@lfarkas.org> <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> <48AE96AA.6090505@lfarkas.org> Message-ID: Hi Farkas, The v2 was simply the second build - no code changes. We are comming out with a new release shortly. I would encourage working with distros as you are. The building of rxtx turns out to be a bottle neck in quick releases. We do want stable releases that work for a year or more but I would have no problems with quicker cycles on developing work. I would have no problem working with someone that did builds that receive less testing more often but they do have to come out for multiple platforms from this end. Thanks for the links. On Fri, 22 Aug 2008, Farkas Levente wrote: > hi, > the packages already build for fedora-9 and centos-5 and here: > http://www.lfarkas.org/linux/packages/ > what i've to patch, the UTS, the configure script, but it's already > fixed in the cvs (in another way) and the loadlibrary. the reasons for > last one can be found here: > https://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_files_that_use_JNI > after we test it i'd like to add these packages to fedora and epel main > repository (that's why it's be useful a new release after 2 years:-) > imho versions are cheap and why not just release 2.1-8? the real code > changes are minimal and if something critical bug found still can > release 2.1-9:-) > > ps. and would be better to use simple number for version like 2.1-7 > rather then 2.1-7v2. > > Oberhuber, Martin wrote: >> Farkas, >> >> there are indeed efforts to get a new RXTX release out the >> door. Your experience as a package maintainer would likely >> be helpful during these efforts, since I'd think it makes >> sense to keep the patches minimal that you must make to >> have the source compile in your environment. >> >> What are the things that you find problematic, apart from >> the UTS thing that you have mentioned before? >> >> What is the timing that you have in mind for your package? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >>> On Behalf Of Farkas Levente >>> Sent: Tuesday, August 19, 2008 4:48 PM >>> To: rxtx at qbang.org >>> Subject: [Rxtx] UTS_RELEASE not defined in newer kernel >>> >>> hi, >>> newer or not so newer linux kernel do not contain the >>> UTS_RELEASE so the >>> current rxtx is not compile on the latest kernels. even if it's >>> commented out in the cvs configure there are other places. >>> i attcahed a patch which fix it (or at least doesn't cause error at >>> non-debug build). >>> >>> ps. is there any plan to the new 2.1-8 release in the near >>> future? there >>> are many changes (at least the license change in all file and in this >>> case create a diff is very difficult)? the latest release more then 2 >>> years old:-( >>> >>> -- >>> Levente "Si vis pacem para bellum!" >>> > > > From andy at triera.net Sat Aug 23 15:17:44 2008 From: andy at triera.net (Andy Rozman) Date: Sat, 23 Aug 2008 21:17:44 +0000 Subject: [Rxtx] port not identified on FreeBSD In-Reply-To: References: Message-ID: <48B07E78.2030306@triera.net> Hi ! I have one small problem... I have started using FreeBSD in last few days and I have come accross a problem with rxtx on FreeBSD. I am using usb-to-serial converter, which is identified under FreeBSD without problem as ucom0, and creates link under /dev called ttyU0, which is correct way to be done under FreeBSD (if device would be unidentified it would be called ugen0 - as usb generic). Problem is that I say to rxtx to get my all serial ports this one is not among them. Which names are permissable under linux-like implementations? Which will be accepted as serial ports? Andy From tjarvi at qbang.org Sat Aug 23 13:57:45 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 23 Aug 2008 13:57:45 -0600 (MDT) Subject: [Rxtx] port not identified on FreeBSD In-Reply-To: <48B07E78.2030306@triera.net> References: <48B07E78.2030306@triera.net> Message-ID: On Sat, 23 Aug 2008, Andy Rozman wrote: > Hi ! > > I have one small problem... I have started using FreeBSD in last few > days and I have come accross a problem with rxtx on FreeBSD. > > I am using usb-to-serial converter, which is identified under FreeBSD > without problem as ucom0, and creates link under /dev called > ttyU0, which is correct way to be done under FreeBSD (if device would be > unidentified it would be called ugen0 - as usb generic). Problem is that > I say to rxtx to get my all serial ports this one is not among them. > Which names are permissable under linux-like implementations? Which will > be accepted as serial ports? > > Andy > Thanks Andy! We will add ttyU* to FreeBSD. For now you can use properties to enable the port. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting#How_does_rxtx_detect_ports.3F__Can_I_override_it.3F The fix: diff -u -r1.16.2.59 RXTXCommDriver.java --- RXTXCommDriver.java 18 Nov 2007 22:32:41 -0000 1.16.2.59 +++ RXTXCommDriver.java 23 Aug 2008 19:55:25 -0000 @@ -644,6 +644,7 @@ { String[] Temp = { "ttyd", //general purpose serial ports + "ttyU", //general purpose USB serial ports "cuaa", //dialout serial ports "ttyA", //Specialix SI/XIO dialin ports "cuaA", //Specialix SI/XIO dialout ports -- Trent Jarvi tjarvi at qbang.org From rick_knight at rlknight.com Mon Aug 4 13:25:10 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Mon, 04 Aug 2008 12:25:10 -0700 Subject: [Rxtx] Sun's Comm API? Message-ID: <48975796.4010600@rlknight.com> I have an application that requires the javax compatible version of RXTX and Sun's comm api. I've been able to download and extract the version of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api anywhere. Can someone tell me where I can find it? Or maybe send me a copy? Also, when I try to build RXTX, configure and make complete successfully but make install failes with this error libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 I've never come accross this error before. How can I get past it? Thanks, Rick From bboyes at systronix.com Mon Aug 4 19:10:01 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:10:01 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48975796.4010600@rlknight.com> References: <48975796.4010600@rlknight.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/cb9c6167/attachment-0036.html From bboyes at systronix.com Mon Aug 4 19:12:37 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:12:37 -0600 Subject: [Rxtx] Towards an RXTX release - CSR BT/USB chipset In-Reply-To: <488FB7E7.8000802@gmail.com> References: <460801A4097E3D4CA04CC64EE648584806C56CF0@ism-mail03.corp.ad.wrs.com> <13557-75390@sneakemail.com> <20980-23424@sneakemail.com> <488FB7E7.8000802@gmail.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/52236088/attachment-0036.html From tjarvi at qbang.org Mon Aug 4 19:42:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 19:42:21 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: On Mon, 4 Aug 2008, Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: > I have an application that requires the javax compatible > version of RXTX > and Sun's comm api. I've been able to download and extract > the version > of RXTX that I need (2.0-7pre2) but I can't find Sun's camm > api > anywhere. Can someone tell me where I can find it? Or maybe > send me a > > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm port > support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have just > a ZIP with only the .class JAR file - no source or docs), has a readme > with these comments: > > This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release.? The 2.0.3 release itself is > no longer distributed.? comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project.? The RxTx project (http://www.rxtx.org ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org) was opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support.? Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins.? Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > ? > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > I hope that is helpful! > It would be nice to work with Sun to resolve those longstanding issues. But it may not be practical unless the process goes as fast and painless as the grandfathering of commapi did. Another option may be the old kaffe extensions that moved to gnu classpathx. These don't have the native libraries but should provide the 2.0 interface and the javax.comm.properties mechansim for SPI. http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Mon Aug 4 20:23:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Mon, 04 Aug 2008 20:23:57 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4897B9BD.5070809@ergotech.com> Has there been any work/would it be possible, to layer a javacomm look-alike on top of the GNU code? The goal is not to move the javax code forward, but to emulate the "legacy" javax packages for people who still need this. Jim Trent Jarvi wrote: > On Mon, 4 Aug 2008, Bruce Boyes wrote: > >> At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible >> version of RXTX >> and Sun's comm api. I've been able to download and extract >> the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm >> api >> anywhere. Can someone tell me where I can find it? Or maybe >> send me a >> >> >> javaxcomm has had a sort of on-again off-again history. The windoze >> version has been languishing for years (literally) but there are newer >> versions for other OS's. >> >> We try to keep links on one of our help pages current: >> http://www.practicalembeddedjava.com/tools/javatools_list.html >> which gets you to here: >> http://java.sun.com/products/javacomm/ >> where it says in fact they no longer even support Windows and Mac: >> "Implementations of the API are currently available for Solaris SPARC, >> Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so >> someone could support it. But I guess that's part of the reason RXTX >> exists! >> >> So one of Sun's own products, SunSPOT, has to use RXTX to get comm port >> support. >> >> The version we use is 2.0 from 11/15/1998. I have posted it on our >> website, which is within the terms of the license agreement contained >> therein (as I understand it). >> >> The last version of javaxcomm for Windows, 2.0.3, (for which I have just >> a ZIP with only the .class JAR file - no source or docs), has a readme >> with these comments: >> >> This distribution contains the comm.jar file original part >> of the COMMAPI 2.0.3 release. The 2.0.3 release itself is >> no longer distributed. comm.jar, which contains the comm >> API java class files (eg. Sun's binary implementation of the >> interface classes), is being made available, unsupported, >> with no obligation to fix bugs, at the request of the RXTX >> project. The RxTx project (http://www.rxtx.org ), uses the >> comm.jar class files, but provides their own native library >> components to provide support for other platforms. >> >> The 2.0.3 comm.jar is being provided in this way because >> as of COMMAPI 3.x, the java binary implementation forked and >> became incompatible with the RxTx project's native code. >> Due to the lack of a clear business case, and to resource >> constraints, no additional resources are being >> provided to provide an alternative engineering solution >> at the time of writing. >> >> RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: >> >> Ultimately the COMMAPI would be better served if a Java >> Community Process JSR (http://www.jcp.org) was opened and >> the COMMAPI was rearchitected to provide a more pluggable >> framework to improve cross-platform support. Such an >> architecture would embody a better defined and better >> documented SPI interface, including a way for comm. ports >> to be revealed to the client application through the API >> via platform-aware plugins. Similarly, native code used >> to access comm port in general could be handled more >> flexibly using a plugin model, whereby on any platform, >> multiple native modules could be in use simultaneously. >> >> Since there are now various ways serial ports can be implemented >> and accessed, modular comm. port JNI native libraries would be >> of benefit insofar as removing the burden of over-generalization >> from any single native component, or inversely, by relieving the >> implicit constraint that comm. drivers be accessed only via a >> monolithic mechanism, such as the UNIX vnode interface. >> >> paul.klissner at sun.com >> 6/10/06 >> >> I hope that is helpful! >> > > It would be nice to work with Sun to resolve those longstanding issues. > But it may not be practical unless the process goes as fast and painless > as the grandfathering of commapi did. > > Another option may be the old kaffe extensions that moved to gnu > classpathx. These don't have the native libraries but should provide > the 2.0 interface and the javax.comm.properties mechansim for SPI. > > http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Mon Aug 4 21:09:15 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 21:09:15 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? Message-ID: Hi Jim, I will not step into the javax.comm namespace without Sun's explicite permission. I fully understand the pain point you are trying to address. In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm Linux) - which remains an integral part of rxtx. At the time it was a win for Sun and rxtx. The Sun commapi license is/was fairly clear that rxtx should not step into that namespace. It made sense as Sun was active in that space and rxtx may go into another namespace - it was an experiment in working with Sun. This may sound silly looking at something that happened almost 10 years ago. In a community of respect which Sun helped create, there is no question about what to do. I hope eventually Sun will step up and do a right thing too. I agree that this is hurting the API more than helping it. There are also questions about how to replace the API in the long term which includes HID support which isn't going well so far. Others that can't even look at Sun's javax.comm today and can look at Kaffe's contribution to classpathx can easily work around such restrictions. On Mon, 4 Aug 2008, Jim Redman wrote: > Has there been any work/would it be possible, to layer a javacomm > look-alike on top of the GNU code? > > The goal is not to move the javax code forward, but to emulate the > "legacy" javax packages for people who still need this. > > Jim > > Trent Jarvi wrote: >> >> It would be nice to work with Sun to resolve those longstanding issues. >> But it may not be practical unless the process goes as fast and painless >> as the grandfathering of commapi did. >> >> Another option may be the old kaffe extensions that moved to gnu >> classpathx. These don't have the native libraries but should provide >> the 2.0 interface and the javax.comm.properties mechansim for SPI. >> >> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From florianmanschwetus at gmx.de Tue Aug 5 05:04:46 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 13:04:46 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: References: <48971C1F.9020806@gmx.de> Message-ID: <489833CE.1040801@gmx.de> Just look at sendCommand in this method I have to place a Thread.sleep(20) after each byte send to get working. Even the event based receive doesn't work fine but this could be may stupidness. The specifikation document (it is on the last pages of the manual) for the beamer could be found on: http://www.optoma.co.uk/support.aspx Florian Manschwetus Trent Jarvi schrieb: > > Hi Florian > > Sorry for the top post in advance. I worry you may not see my answer > under all your code :) > > I have not received this email before. This is 500k of code which I > don't have time to read. I can spend about 5 min on each hobby email > and still get to work in the morning. I have a couple suggestions for > how to get an answer. > > First, cut out your comments and extra code so you can demonstrate the > question (I might even glance and see what is wrong then). Don't go for > a working final product. Isolate the problem using a simple program and > then ask with that as an example. If I did what you just did, I'd have > to post 3/4 of a million lines of code :) > > Second, join the rxtx mail-list and ask there. This will give you 100x > more eyes. I'll also read and try to follow. > > -- > taj > > > > On Mon, 4 Aug 2008, Florian Manschwetus wrote: > >> It could be that my university account is blocked by filters so >> resending from here. >> >> >> Topic is to control Optoma HD80 beamer using rs232 serial chat. >> This code is able to detect power state and switch the beamer on / off. >> connected is the beamer using a digitus usb 2.0 serial adapter with an >> FT232 USB-Serial adapter the systems architecture is amd64. >> >> Please take a look in the sendCommand routine i have to place theire >> those Thread.sleep to get it working. >> Now the question is this correct or is there a better way to get this >> working correctly? >> >> In the javadoc coming with the install i found this: >> setBaudBase >> >> public boolean setBaudBase(int BaudBase) >> throws UnsupportedCommOperationException, >> java.io.IOException >> >> Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 >> before using. >> >> could this explain the error? >> I attached my java source and the protocol description for the beamer >> (available on vendor website). >> >> thx, >> Florian Manschwetus >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: TestRS232.java Type: text/x-java Size: 9143 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0072.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0073.bin From michael.erskine at ketech.com Tue Aug 5 05:53:49 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Tue, 5 Aug 2008 12:53:49 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489833CE.1040801@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> > Just look at sendCommand in this method I have to place a > Thread.sleep(20) after each byte send to get working. Even the event > based receive doesn't work fine but this could be may stupidness. Hi Florian, Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. Regards, Michael Erskine. From florianmanschwetus at gmx.de Tue Aug 5 07:28:15 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:28:15 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> Message-ID: <4898556F.8000208@gmx.de> Michael Erskine schrieb: >> Just look at sendCommand in this method I have to place a >> Thread.sleep(20) after each byte send to get working. Even the event >> based receive doesn't work fine but this could be may stupidness. > > Hi Florian, > > Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. > > Regards, > Michael Erskine. > Ok, sounds fine for the receiving problem. But why i have to wait after each byte when sending a command squence? (the for loop in send command) Florian > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/284f350c/attachment-0035.bin From florianmanschwetus at gmx.de Tue Aug 5 07:44:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:44:14 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <4898592E.2020908@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >>> Just look at sendCommand in this method I have to place a >>> Thread.sleep(20) after each byte send to get working. Even the event >>> based receive doesn't work fine but this could be may stupidness. >> >> Hi Florian, >> >> Yes, naturally you'll have to wait for a response from the other end. >> Why not wait for notification from the event thread perhaps using a >> BlockingDeque rather than your LinkedList. Generally I >> try to decouple all input and output streams: in your case your >> application is operating synchronously like the "expect" program >> (http://expect.nist.gov/) so waits (or timeouts) will need to be >> factored in. >> >> Regards, >> Michael Erskine. >> > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) > > Florian Furthermore there is this basic baud with this confusing javadoc entry: public boolean setBaudBase(int BaudBase) throws UnsupportedCommOperationException, java.io.IOException Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 before using. maybe this could explain something Florian >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/006c7425/attachment-0035.bin From jredman at ergotech.com Tue Aug 5 09:13:36 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 05 Aug 2008 09:13:36 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: Message-ID: <48986E20.3060104@ergotech.com> Trent, So two issues: 1) Technically I'm still not sure how easy/practical a layer would be. The problems are always classes like listeners, and wrapping returns of gnu.io classes. I really see it as a "delegate" type of concept. Any thoughts or ideas of the practicality of this approach? The idea is not to modify RXTX. 2) Javax. The javax namespace does seem to be in widespread use outside of Sun (the same is true for the java namespace). The classpath extensions, or some other location, should be interested in a JavaComm implementation even if it does have dependencies on RXTX. Would you have any philosophical objection to an approach like that? Of course, I suspect it might be better if someone with that authority at Sun would admit that the javax namespace is already in the wild and that there is no problem with it being used within RXTX. Jim Trent Jarvi wrote: > Hi Jim, > > I will not step into the javax.comm namespace without Sun's explicite > permission. I fully understand the pain point you are trying to address. > > In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm > Linux) - which remains an integral part of rxtx. At the time it was a win for > Sun and rxtx. > > The Sun commapi license is/was fairly clear that rxtx should not step into that > namespace. It made sense as Sun was active in that space and rxtx may go into > another namespace - it was an experiment in working with Sun. > > This may sound silly looking at something that happened almost 10 years ago. > In a community of respect which Sun helped create, there is no question about > what to do. I hope eventually Sun will step up and do a right thing too. > > I agree that this is hurting the API more than helping it. There are also > questions about how to replace the API in the long term which includes HID > support which isn't going well so far. > > Others that can't even look at Sun's javax.comm today and can look at Kaffe's > contribution to classpathx can easily work around such restrictions. > > On Mon, 4 Aug 2008, Jim Redman wrote: > >> Has there been any work/would it be possible, to layer a javacomm >> look-alike on top of the GNU code? >> >> The goal is not to move the javax code forward, but to emulate the >> "legacy" javax packages for people who still need this. >> >> Jim >> >> Trent Jarvi wrote: >>> It would be nice to work with Sun to resolve those longstanding issues. >>> But it may not be practical unless the process goes as fast and painless >>> as the grandfathering of commapi did. >>> >>> Another option may be the old kaffe extensions that moved to gnu >>> classpathx. These don't have the native libraries but should provide >>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>> >>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From sandeep at genevasoftech.com Tue Aug 5 11:18:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Tue, 05 Aug 2008 22:48:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <48988B6C.5080409@genevasoftech.com> Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. *-- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/ad20f1cb/attachment-0035.html From Martin.Oberhuber at windriver.com Tue Aug 5 13:30:17 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Tue, 5 Aug 2008 21:30:17 +0200 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Sandeep, shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on Sol7 but I've successfully run it on Sol9 and Sol10. Or is your request really about a native 64bit variant? I'm afraid that then you're out of luck since I think that quite a bit of RXTX is not yet ready for 64 bit. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Sandeep Kumar K Sent: Tuesday, August 05, 2008 7:19 PM To: rxtx at qbang.org Subject: [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so for Solaris 9 Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. -- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/81b7f988/attachment-0035.html From tjarvi at qbang.org Tue Aug 5 22:38:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 22:38:34 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 5 Aug 2008, Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built > on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid that > then > you're out of luck since I think that quite a bit of RXTX is not yet > ready > for 64 bit. > While rxtx-2.1-7 probably has problems, The CVS code should be OK for 64 bit Solaris. If it isn't, let me know and I'll find which patch is missing. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Aug 5 23:13:00 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 23:13:00 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48986E20.3060104@ergotech.com> References: <48986E20.3060104@ergotech.com> Message-ID: On Tue, 5 Aug 2008, Jim Redman wrote: > Trent, > > So two issues: > > 1) Technically I'm still not sure how easy/practical a layer would be. The > problems are always classes like listeners, and wrapping returns of gnu.io > classes. I really see it as a "delegate" type of concept. Any thoughts or > ideas of the practicality of this approach? The idea is not to modify RXTX. I have not put too much thought into this. I assume you want what rxtx 2.0 provided to tie into javax.comm implementations. More classes could be added to rxtx 2.1-7 for SPI support. Maintaining rxtx-2.0 could also be handed to someone if they like. > > 2) Javax. The javax namespace does seem to be in widespread use outside of > Sun (the same is true for the java namespace). The classpath extensions, or > some other location, should be interested in a JavaComm implementation even > if it does have dependencies on RXTX. Would you have any philosophical > objection to an approach like that? > No problems. Classpathx would be a possible place to do it. I'd suggest thinking twice about what this involves in practical terms. You would be wanting to revive the 2.0 API while Sun is at 3.0 and grandfathering the JSR. This undermines the main reason (established api) for using the javax.comm namespace and does not leave such a project in a good position. The only win I see here is maintaining support for applications that can't migrate namespaces. Not that that isn't important. At some point it is going to be less work to just edit the bytecode :) Such a javax.comm effort would also be signing up new projects that decided to use the work up for concerns they probably will not understand or expect. That probably isn't a good path to facilitate for new projects at this time. We will put a good faith effort to work well with others but keep in mind the project has limited bandwidth for such efforts. > Of course, I suspect it might be better if someone with that authority at Sun > would admit that the javax namespace is already in the wild and that there is > no problem with it being used within RXTX. > > Jim > > Trent Jarvi wrote: >> Hi Jim, >> >> I will not step into the javax.comm namespace without Sun's explicite >> permission. I fully understand the pain point you are trying to address. >> >> In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java >> Comm Linux) - which remains an integral part of rxtx. At the time it was a >> win for Sun and rxtx. >> >> The Sun commapi license is/was fairly clear that rxtx should not step into >> that namespace. It made sense as Sun was active in that space and rxtx may >> go into another namespace - it was an experiment in working with Sun. >> >> This may sound silly looking at something that happened almost 10 years >> ago. In a community of respect which Sun helped create, there is no >> question about what to do. I hope eventually Sun will step up and do a >> right thing too. >> >> I agree that this is hurting the API more than helping it. There are also >> questions about how to replace the API in the long term which includes HID >> support which isn't going well so far. >> >> Others that can't even look at Sun's javax.comm today and can look at >> Kaffe's contribution to classpathx can easily work around such >> restrictions. >> >> On Mon, 4 Aug 2008, Jim Redman wrote: >> >>> Has there been any work/would it be possible, to layer a javacomm >>> look-alike on top of the GNU code? >>> >>> The goal is not to move the javax code forward, but to emulate the >>> "legacy" javax packages for people who still need this. >>> >>> Jim >>> >>> Trent Jarvi wrote: >>>> It would be nice to work with Sun to resolve those longstanding issues. >>>> But it may not be practical unless the process goes as fast and painless >>>> as the grandfathering of commapi did. >>>> >>>> Another option may be the old kaffe extensions that moved to gnu >>>> classpathx. These don't have the native libraries but should provide >>>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>>> >>>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From sandeep at genevasoftech.com Wed Aug 6 00:03:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Wed, 06 Aug 2008 11:33:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: <48993EB8.30107@genevasoftech.com> Thank you Mr. Martin for your suggestion. The native file which is given in rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am getting the following error . Any suggestions to solve this issue. I am using Solaris SPARC 64 bit machine. ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) thrown while loading gnu.io.RXTXCommDriver Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(Unknown Source) at java.lang.ClassLoader.loadLibrary(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) at com.ReadFromModem.main(ReadFromModem.java:84) * * *Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid > that then > you're out of luck since I think that quite a bit of RXTX is not yet ready > for 64 bit. > > Cheers, > -- > *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > ------------------------------------------------------------------------ > *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On > Behalf Of *Sandeep Kumar K > *Sent:* Tuesday, August 05, 2008 7:19 PM > *To:* rxtx at qbang.org > *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so > for Solaris 9 > > Hi, > > Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 > bit machine. The librxtxSerial.so given in website is for Solaris 8. > > *-- > > Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/1e920343/attachment-0035.html From tjarvi at qbang.org Wed Aug 6 00:21:42 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 00:21:42 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <48993EB8.30107@genevasoftech.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> <48993EB8.30107@genevasoftech.com> Message-ID: Hi Sandeep You may be out of luck unless you can compile the 2.1 src in CVS (requires gnu make and gcc). But you could try the ToyBox(R)(TM) which is a collection of WiLdLy untested cross compiled 2.1-7 binaries covering everything from the ibm z series to embeded arm/ppc. To give an idea how poorly these are tested, I don't even know if z series machines have a serial port. ftp://www.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Solaris They should at least match the binary types. Actually, I think if you use the rxtx jar from CVS with that file, it should 'work' as the fix for 64 bits was in java not the native code. You could just cd rxtx*/src; javac *.java then jar -cf RXTXcomm.jar `find -name \*.class` to create the hybrid which will complain about version information a bit. On Wed, 6 Aug 2008, Sandeep Kumar K wrote: > Thank you Mr. Martin for your suggestion. The native file which is given in > rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am > getting the following error . > Any suggestions to solve this issue. > I am using Solaris SPARC 64 bit machine. > > ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar > java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 > (Possible cause: architecture word > width mismatch) thrown while loading gnu.io.RXTXCommDriver > Exception in thread "main" java.lang.UnsatisfiedLinkError: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF > class: ELFCLASS64 (Possible cause: > architecture word width mismatch) > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(Unknown Source) > at java.lang.ClassLoader.loadLibrary(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > at com.ReadFromModem.main(ReadFromModem.java:84) > > * > * > > *Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > > > Oberhuber, Martin wrote: >> Sandeep, >> shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse >> variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on >> Sol7 but I've successfully run it on Sol9 and Sol10. >> Or is your request really about a native 64bit variant? I'm afraid that >> then >> you're out of luck since I think that quite a bit of RXTX is not yet ready >> for 64 bit. >> Cheers, >> -- >> *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> ------------------------------------------------------------------------ >> *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On >> Behalf Of *Sandeep Kumar K >> *Sent:* Tuesday, August 05, 2008 7:19 PM >> *To:* rxtx at qbang.org >> *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so >> for Solaris 9 >> >> Hi, >> >> Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 >> bit machine. The librxtxSerial.so given in website is for Solaris 8. >> >> *-- >> Thanks & Regards >> >> Sandeep Kumar K >> Sr. Software Engineer >> Geneva Software Technologies >> Whitefield, Bangalore >> Mob : 9880193454* >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> From michael.erskine at ketech.com Wed Aug 6 01:39:28 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 6 Aug 2008 08:39:28 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Florian Manschwetus wrote: > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) Hi Florian, I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. Regards, Michael Erskine. From florianmanschwetus at gmx.de Wed Aug 6 02:53:16 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 06 Aug 2008 10:53:16 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Message-ID: <4899667C.6010706@gmx.de> Michael Erskine schrieb: > Florian Manschwetus wrote: >> Ok, sounds fine for the receiving problem. >> But why i have to wait after each byte when sending a command squence? >> (the for loop in send command) > > Hi Florian, > I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. > > Regards, > Michael Erskine. > correct with a terminal on the other end it works, my idea was that this basic baud has some influence. Could some one explain what it is for? Florian > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/c2b4fa84/attachment-0035.bin From rick_knight at rlknight.com Wed Aug 6 13:01:07 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:01:07 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F4F3.3020707@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > I have an application (Readerware) that uses RXTX with Javax to access the serial port. This used to work fine under previous Linux' and Java, but something has changed, I assume with Java itself , that is causing the application to fail with a link error. The application is not able to find librxtxSerialParallel.so. RXTX supplies librxtxSerial.so and librxtxParallel.so, but not librxtxSerialParallel.so. Where can I get librxtxSerialParallel.so, or do I need it? Is something else causing the lib to not be found? Thanks, Rick Knight From rick_knight at rlknight.com Wed Aug 6 13:17:55 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:17:55 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F8E3.5060400@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Thanks for the reply. The developer of the app I'm trying to use (Readerware) has sent me a copy of the comm.api and I've copied the library (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar into the proper places. When I try to run the application, I get this error... Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: /usr/lib/libSolarisSerialParallel.so: /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not little-endian (Possible cause: endianness mismatch) Caught java.lang.UnsatisfiedLinkError: com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I while loading driver com.sun.comm.SolarisDriver Is there a way around this error? Thanks again, Rick Knight From jlar310 at gmail.com Wed Aug 6 13:37:42 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 14:37:42 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899F8E3.5060400@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > The developer of the app I'm trying to use (Readerware) has sent me a > copy of the comm.api and I've copied the library > (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar > into the proper places. When I try to run the application, I get this > error... > > Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: > /usr/lib/libSolarisSerialParallel.so: > /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not > little-endian (Possible cause: endianness mismatch) > Caught java.lang.UnsatisfiedLinkError: > com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I > > while loading driver com.sun.comm.SolarisDriver > > Is there a way around this error? What host OS are you running? From your original post it looks like 32 bit Linux. The libSolarisSerialParallel.so file is for Sun Solaris and will vary depending on the underlying hardware architecture as well. Sorry for the double post Rick, but I failed to send this to the list the first time... -- Jeff From rick_knight at rlknight.com Wed Aug 6 13:44:29 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:44:29 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: <4899FF1D.9030504@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > > >> The developer of the app I'm trying to use (Readerware) has sent me a >> copy of the comm.api and I've copied the library >> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >> into the proper places. When I try to run the application, I get this >> error... >> >> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >> /usr/lib/libSolarisSerialParallel.so: >> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >> little-endian (Possible cause: endianness mismatch) >> Caught java.lang.UnsatisfiedLinkError: >> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >> >> while loading driver com.sun.comm.SolarisDriver >> >> Is there a way around this error? >> > > What host OS are you running? From your original post it looks like 32 > bit Linux. > > The libSolarisSerialParallel.so file is for Sun Solaris and will vary > depending on the underlying hardware architecture as well. > > I'm running Kubuntu Linux (debian based). It's 32 bit. Rick Knight From jlar310 at gmail.com Wed Aug 6 15:33:23 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 16:33:23 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > I don't think Sun did binary libraries for Linux in the 2.0 version. Can someone with more historical experience than I confirm that? I recently tried to port a Comm API application from Solaris sparc to Linux x86 and likewise could not get my hands on the binary libraries. I eventually just re-wrote the code to use the gnu namespace packages and rxtx 2.1. What I don't understand is why your application vendor does not provide everything you need to run their software. FYI: I have librxtxParallel.so and librxtxSerial.so installed at JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is /usr/java/default which is actually a softlink to /usr/java/jre1.6.0_05. -- Jeff From defiantlew at yahoo.com.au Wed Aug 6 16:29:33 2008 From: defiantlew at yahoo.com.au (Lew L) Date: Thu, 7 Aug 2008 08:29:33 +1000 Subject: [Rxtx] Sun's Comm API Documentation References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> Message-ID: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> As a matter of interest is the Sun Comm API documentation available somewhere? I have tried the Sun site but it seems to have been removed. Unless I have missed the documentation for RXTX? I javadocced the RXTX source but information (to me) is minimal. Somewhere I got the impression that the Sun Comm API docs is, or was, compatible with RXTX, what is the best docs to use in conjuntion with RXTX and where may the be available? Cheers Lew From rick_knight at rlknight.com Wed Aug 6 17:18:33 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:18:33 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A3149.4050306@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff I'm not sure if I posted this here or not, but when I try to build RXTX from source I get this install error... make all-am make[1]: Entering directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' make[1]: Nothing to be done for `all-am'. make[1]: Leaving directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 Can you tell me how to get past this error and get RXTX built and installed? Thanks, Rick From bboyes at systronix.com Wed Aug 6 17:40:12 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Wed, 06 Aug 2008 17:40:12 -0600 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: At 16:29 08/06/2008, Lew L wrote: >As a matter of interest is the Sun Comm API documentation available >somewhere? I have tried the Sun site but it seems to have been removed. It's in the file we have posted, link in prev email (sorry, in a huge hurry right now). Javadocs definitely there. >Unless I have missed the documentation for RXTX? I javadocced the RXTX >source but information (to me) is minimal. >Somewhere I got the impression that the Sun Comm API docs is, or was, >compatible with RXTX, what is the best docs to use in conjuntion with RXTX >and where may the be available? Yeah, this is one of my concerns/beefs. There is little documentation for RXTX and it isn't just the same as javaxcomm. I would be willing to help out writing docs for RXTX! Yes really... esp if we can fix the Bluetooth issues. best regards Bruce >Cheers >Lew > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx ------- WWW.SYSTRONIX.COM ---------- Real embedded Java and much more +1-801-534-1017 Salt Lake City, USA From rick_knight at rlknight.com Wed Aug 6 17:54:08 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:54:08 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A39A0.2090309@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff, I would like for my vendor to switch to rxtx 2.1. It would make things much easier for me. I'm not sure why he's still using the javax compatible code. He's a small operation. Re-writing the code to use gnu namespace sounds like a major overhaul. Was it? Thanks, Rick From tjarvi at qbang.org Wed Aug 6 21:35:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:35:12 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: >> >>> Jeff wrote: >>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>>> >>>> >>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things > much easier for me. I'm not sure why he's still using the javax > compatible code. He's a small operation. Re-writing the code to use gnu > namespace sounds like a major overhaul. Was it? > Hi Jeff, The changes are fairly mechanical. Imports need to change and any explicite use of the namespace needs to change such as catching an exception. The following script was made for maintaining rxtx 2.0 but can apply to other needs. It is in the contrib dir with rxtx source. #!/bin/sh # Don't use! :) # # Sat, 03 May 2003 16:45:08 Modifications from J?rg Weule # Create a ed-cmd for the change of one pattern # case $1 in gnu) X=g/javax_comm/s+javax_comm+gnu_io+g ;; javax) X=g/gnu_io/s+gnu_io+javax_comm+g ;; *) echo;echo;echo From the top rxtx directory run;echo;echo -e \\t./ChangePackage.sh gnu;echo -e \\t\\tor;echo -e \\t./ChangePackage.sh javax;echo;echo; exit 0 ;; esac # # ed will be used to keep the owner and mode of the files unchanged. # We have run the ed-script for the characters '.' '/' as well. # "tr _ $D" do the change. # find . -type f -a -print | grep -v $0 | (while read F ; do ( echo $X; echo $X| tr _ /; echo $X| tr _ .; echo w; echo q ) | ed $F 2>&1 >/dev/null done ) # # Now we do little changes at the Makefiles. Hope that all we need. # find . -name Makefile\* -a -print | (while read F ; do cat < References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: On Thu, 7 Aug 2008, Lew L wrote: > As a matter of interest is the Sun Comm API documentation available > somewhere? I have tried the Sun site but it seems to have been removed. > > Unless I have missed the documentation for RXTX? I javadocced the RXTX > source but information (to me) is minimal. > Somewhere I got the impression that the Sun Comm API docs is, or was, > compatible with RXTX, what is the best docs to use in conjuntion with RXTX > and where may the be available? > Hi Lew, The documentation on Sun's website is accurate. The changes that are problematic in 3.0 are on the backside which rxtx used to plug into. http://java.sun.com/products/javacomm/reference/api/index.html CommPortIdentifier may have some minor differences (judging by the authors notes). -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Aug 6 21:46:08 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:46:08 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > If javax.comm.properties is properly installed and you are using a 2.0 version of Sun's commapi with rxtx 2.0, you should not see the library attempt to load libSolarisSerialParallel.so. Sun CommAPI 3.0 will not work with any version of rxtx as it is hard coded to use the shared library. See the INSTALL file with rxtx-2.0 source for more help with the properties file. -- Trent Jarvi tjarvi at qbang.org From jlar310 at gmail.com Thu Aug 7 06:32:06 2008 From: jlar310 at gmail.com (Jeff) Date: Thu, 7 Aug 2008 07:32:06 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > Jeff wrote: >> >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >> wrote: >> >>> >>> Jeff wrote: >>> >>>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>> wrote: >>>> >>>> >>>> >>>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things much > easier for me. I'm not sure why he's still using the javax compatible code. > He's a small operation. Re-writing the code to use gnu namespace sounds like > a major overhaul. Was it? I found it quite easy. In fact, in order to accommodate the transition, I actually separated all of the code that deals directly with the Comm API or RXTX into a helper class. The helper class was then coded to use reflection to determine which library was available and then instantiate the necessary objects. No direct imports of either library are used. The main application just needs to get it's hands on the IO streams and need not deal directly with the libraries. Other programs may not be so simple... But this doesn't really help you unless your vendor forks over the source code... -- Jeff From rick_knight at rlknight.com Thu Aug 7 09:47:12 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Thu, 07 Aug 2008 08:47:12 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: <489B1900.10108@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >>> wrote: >>> >>> >>>> Jeff wrote: >>>> >>>> >>>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>>> copy of the comm.api and I've copied the library >>>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>>> into the proper places. When I try to run the application, I get this >>>>>> error... >>>>>> >>>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>>> /usr/lib/libSolarisSerialParallel.so: >>>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>>> little-endian (Possible cause: endianness mismatch) >>>>>> Caught java.lang.UnsatisfiedLinkError: >>>>>> >>>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>>> >>>>>> while loading driver com.sun.comm.SolarisDriver >>>>>> >>>>>> Is there a way around this error? >>>>>> >>>>>> >>>>>> >>>>> What host OS are you running? From your original post it looks like 32 >>>>> bit Linux. >>>>> >>>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>>> depending on the underlying hardware architecture as well. >>>>> >>>>> >>>>> >>>>> >>>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>>> >>>> >>>> >>> I don't think Sun did binary libraries for Linux in the 2.0 version. >>> Can someone with more historical experience than I confirm that? >>> >>> I recently tried to port a Comm API application from Solaris sparc to >>> Linux x86 and likewise could not get my hands on the binary libraries. >>> I eventually just re-wrote the code to use the gnu namespace packages >>> and rxtx 2.1. >>> >>> What I don't understand is why your application vendor does not >>> provide everything you need to run their software. >>> >>> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >>> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >>> /usr/java/default which is actually a softlink to >>> /usr/java/jre1.6.0_05. >>> >>> >>> >> Jeff, >> >> I would like for my vendor to switch to rxtx 2.1. It would make things much >> easier for me. I'm not sure why he's still using the javax compatible code. >> He's a small operation. Re-writing the code to use gnu namespace sounds like >> a major overhaul. Was it? >> > > I found it quite easy. In fact, in order to accommodate the > transition, I actually separated all of the code that deals directly > with the Comm API or RXTX into a helper class. The helper class was > then coded to use reflection to determine which library was available > and then instantiate the necessary objects. No direct imports of > either library are used. The main application just needs to get it's > hands on the IO streams and need not deal directly with the libraries. > Other programs may not be so simple... > > But this doesn't really help you unless your vendor forks over the > source code... > > Jeff, This may not help me directly, but I'm going to forward this thread to the vendor. I think he'll be open to making things work. Thanks again, Rick Knight From agusmunioz at gmail.com Thu Aug 7 16:39:51 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Thu, 7 Aug 2008 19:39:51 -0300 Subject: [Rxtx] How to send ack? Message-ID: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Hi, I'm still learning about serial communication and I have some doubts. I've got this question about how to do the following thing in rxtx. I have this hardware that connect to a PC using a serial port. These hardware receives data from a telephone line, proccess it, and then send it forward to the serial port. I've used a program named wincomm that shows what information is send it through the serial port and I have the nex behaviour: The hardware has a buffer where all data is stored, that cannot be sent it through the seria port. The program reads the first data send it by the hardware, and keep reading the same data always. There is a button in the application that says enable Ack, and when I click, then the hardware start to send all the stored information, and all the information is shown. I write a class, using rxtx that reads the serial port, and the same thing happens, it remains reading the same (first) data all the time. And I thing something like the enable Ack I'm missing. How can I do this enable Ack from my java code using rxtx? Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080807/e0a0f9a1/attachment-0033.html From ajmas at sympatico.ca Thu Aug 7 18:26:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 7 Aug 2008 20:26:41 -0400 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: <4BF42297-81E2-4BB8-A89F-1D43588379AE@sympatico.ca> On 6-Aug-08, at 19:40 , Bruce Boyes wrote: >> Unless I have missed the documentation for RXTX? I javadocced the >> RXTX >> source but information (to me) is minimal. >> Somewhere I got the impression that the Sun Comm API docs is, or was, >> compatible with RXTX, what is the best docs to use in conjuntion >> with RXTX >> and where may the be available? > > Yeah, this is one of my concerns/beefs. There is little documentation > for RXTX and it isn't just the same as javaxcomm. > > I would be willing to help out writing docs for RXTX! Yes really... > esp if we can fix the Bluetooth issues. If you want to contribute documentation then the best place to do that is the wiki. If there is anything missing or that could be improved on then please do so. If there are any points that you would like to see improved, for which you don't have the knowledge then ask on the mailing list for a volunteer. Andre From florianmanschwetus at gmx.de Fri Aug 8 03:04:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Fri, 08 Aug 2008 11:04:14 +0200 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Message-ID: <489C0C0E.2020401@gmx.de> Agustin Mu?oz schrieb: > Hi, I'm still learning about serial communication and I have some > doubts. I've got this question about how to do the following thing in rxtx. > I have this hardware that connect to a PC using a serial port. These > hardware receives data from a telephone line, proccess it, and then send > it forward to the serial port. I've used a program named wincomm that > shows what information is send it through the serial port and I have the > nex behaviour: > > The hardware has a buffer where all data is stored, that cannot be sent > it through the seria port. > The program reads the first data send it by the hardware, and keep > reading the same data always. > There is a button in the application that says enable Ack, and when I > click, then the hardware start to send all the stored information, and > all the information is shown. > > I write a class, using rxtx that reads the serial port, and the same > thing happens, it remains reading the same (first) data all the time. > And I thing something like the enable Ack I'm missing. > How can I do this enable Ack from my java code using rxtx? Afaik, a look at man ascii reveals: Okt Dez Hex Char 006 6 06 ACK So, i hope this will do the job: send(6); florian > > Thanks in advance > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/5b4965f8/attachment-0033.bin From agusmunioz at gmail.com Fri Aug 8 16:31:00 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 19:31:00 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <489C0C0E.2020401@gmx.de> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> Message-ID: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Hi Florian, thanks for the answer. By send(6) you mean to get the port OutputStream and write a 6? I try that but it didn't work. Any suggestion? Thanks On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < florianmanschwetus at gmx.de> wrote: > Agustin Mu?oz schrieb: > > Hi, I'm still learning about serial communication and I have some doubts. >> I've got this question about how to do the following thing in rxtx. >> I have this hardware that connect to a PC using a serial port. These >> hardware receives data from a telephone line, proccess it, and then send it >> forward to the serial port. I've used a program named wincomm that shows >> what information is send it through the serial port and I have the nex >> behaviour: >> >> The hardware has a buffer where all data is stored, that cannot be sent >> it through the seria port. >> The program reads the first data send it by the hardware, and keep reading >> the same data always. >> There is a button in the application that says enable Ack, and when I >> click, then the hardware start to send all the stored information, and all >> the information is shown. >> >> I write a class, using rxtx that reads the serial port, and the same thing >> happens, it remains reading the same (first) data all the time. And I thing >> something like the enable Ack I'm missing. >> How can I do this enable Ack from my java code using rxtx? >> > Afaik, a look at man ascii reveals: > Okt Dez Hex Char > 006 6 06 ACK > So, i hope this will do the job: > send(6); > > florian > >> >> Thanks in advance >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/7f3fba42/attachment-0032.html From agusmunioz at gmail.com Fri Aug 8 18:39:27 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 21:39:27 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Message-ID: <988288430808081739x7f9e7889id82591d5a9e2b4f6@mail.gmail.com> Ok, Florian, it works!! my problem was that I've been sending, through the OutputStream, the bytes of 6 as a string: out.write("6".getBytes()); but then I realized that you can write an int on an OuptuStream, so I tried that and It works: out.write(6); Thank you for the guidance!! On Fri, Aug 8, 2008 at 7:31 PM, Agustin Mu?oz wrote: > Hi Florian, thanks for the answer. By send(6) you mean to get the port > OutputStream and write a 6? > > I try that but it didn't work. > > Any suggestion? > > Thanks > > > On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < > florianmanschwetus at gmx.de> wrote: > >> Agustin Mu?oz schrieb: >> >> Hi, I'm still learning about serial communication and I have some doubts. >>> I've got this question about how to do the following thing in rxtx. >>> I have this hardware that connect to a PC using a serial port. These >>> hardware receives data from a telephone line, proccess it, and then send it >>> forward to the serial port. I've used a program named wincomm that shows >>> what information is send it through the serial port and I have the nex >>> behaviour: >>> >>> The hardware has a buffer where all data is stored, that cannot be sent >>> it through the seria port. >>> The program reads the first data send it by the hardware, and keep >>> reading the same data always. >>> There is a button in the application that says enable Ack, and when I >>> click, then the hardware start to send all the stored information, and all >>> the information is shown. >>> >>> I write a class, using rxtx that reads the serial port, and the same >>> thing happens, it remains reading the same (first) data all the time. And I >>> thing something like the enable Ack I'm missing. >>> How can I do this enable Ack from my java code using rxtx? >>> >> Afaik, a look at man ascii reveals: >> Okt Dez Hex Char >> 006 6 06 ACK >> So, i hope this will do the job: >> send(6); >> >> florian >> >>> >>> Thanks in advance >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/b918ab3d/attachment-0032.html From florianmanschwetus at gmx.de Sat Aug 9 00:45:43 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Sat, 09 Aug 2008 08:45:43 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4899667C.6010706@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> Message-ID: <489D3D17.9090209@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >> Florian Manschwetus wrote: >>> Ok, sounds fine for the receiving problem. >>> But why i have to wait after each byte when sending a command squence? >>> (the for loop in send command) >> >> Hi Florian, >> I'd imagine you probably don't! You could send all bytes in one go and >> RXTX would send them. The problem is most probably the other end: >> perhaps it has a really small buffer, some non-standard UART, or a >> crazy timing issue. If you attach a terminal to your output and send >> all the bytes of a command in one go they should appear no problem. >> >> Regards, >> Michael Erskine. >> > correct with a terminal on the other end it works, my idea was that this > basic baud has some influence. Could some one explain what it is for? > > Florian To make it more clear, my problem is that i can't use: outputStream.write(byte[]); => Beamer doesn't understand the sequence. (mostly no answer when he answers then *001) when i use this construct instead: for (int i = 0; i < command.length; i++) { this.outputStream.write(command[i]); try { Thread.sleep(25); } catch (InterruptedException e) { // TODO Auto-generated catch block e.printStackTrace(); } } it works nearly reliable. So what could it be? This Basic Baud is what exactly? Florian -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080809/692304ee/attachment-0032.bin From tjarvi at qbang.org Sat Aug 9 16:37:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Aug 2008 16:37:19 -0600 (MDT) Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489D3D17.9090209@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> <489D3D17.9090209@gmx.de> Message-ID: On Sat, 9 Aug 2008, Florian Manschwetus wrote: > Florian Manschwetus schrieb: >> Michael Erskine schrieb: >>> Florian Manschwetus wrote: >>>> Ok, sounds fine for the receiving problem. >>>> But why i have to wait after each byte when sending a command squence? >>>> (the for loop in send command) >>> >>> Hi Florian, >>> I'd imagine you probably don't! You could send all bytes in one go and >>> RXTX would send them. The problem is most probably the other end: perhaps >>> it has a really small buffer, some non-standard UART, or a crazy timing >>> issue. If you attach a terminal to your output and send all the bytes of a >>> command in one go they should appear no problem. >>> >>> Regards, >>> Michael Erskine. >>> >> correct with a terminal on the other end it works, my idea was that this >> basic baud has some influence. Could some one explain what it is for? >> >> Florian > To make it more clear, > my problem is that i can't use: > outputStream.write(byte[]); > => Beamer doesn't understand the sequence. (mostly no answer when he answers > then *001) > > when i use this construct instead: > > for (int i = 0; i < command.length; i++) { > this.outputStream.write(command[i]); > try { > Thread.sleep(25); > } catch (InterruptedException e) { > // TODO Auto-generated catch block > e.printStackTrace(); > } > } > > it works nearly reliable. > > So what could it be? This Basic Baud is what exactly? > I suspect you are using the 'moon protocol' and don't know it. RXTX enables this by default. The buffer on the other end is first in first out while reading. If the buffer is full, the bits are hand carried to the moon and burried. Then if the other side reads a couple bytes, two more bytes go into the buffer followed by more moon protocol. The resulting array of bytes the other side reads may appear to be scrambled until you go to the moon, get the bits and insert them in the right place. Flow control can prevent the default moon protocol and throttles the communiation by almost writing a byte at a time as need be. Hardware flow control is preferable but software flow control should also work. Read and write can appear to hang if the other side is not connected. This is why we don't enable them all the time. If you can't use flow control, you have to take care with the moon protocol and give the other side time to read. That is what your slower version of write is doing. -- Trent Jarvi tjarvi at qbang.org From rxtx at allenjb.me.uk Mon Aug 11 08:06:36 2008 From: rxtx at allenjb.me.uk (AllenJB) Date: Mon, 11 Aug 2008 15:06:36 +0100 Subject: [Rxtx] Disabling EV_RXFLAG Message-ID: <48A0476C.2090800@allenjb.me.uk> Hi all, I'm working with a device which does not use an EvtChar and need to disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an event mask of FD 01 00 00. The reference software I have uses FB 00 00 00. With the rxtx mask I get framing errors which I believe are caused when the EvtChar is received. Is there currently a way with rxtx (I've using rxtx from Java) to disable EV_RXFLAG? If not from Java, where would I start if I wanted to turn the EV_RXFLAG option off in the C code? I've had a grep of the rxtx source code, but I can't see where EV_RXFLAG is being set. Thanks in advance, AllenJB From tjarvi at qbang.org Mon Aug 11 14:17:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Aug 2008 14:17:27 -0600 (MDT) Subject: [Rxtx] Disabling EV_RXFLAG In-Reply-To: <48A0476C.2090800@allenjb.me.uk> References: <48A0476C.2090800@allenjb.me.uk> Message-ID: On Mon, 11 Aug 2008, AllenJB wrote: > Hi all, > > I'm working with a device which does not use an EvtChar and need to > disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an > event mask of FD 01 00 00. The reference software I have uses FB 00 00 > 00. With the rxtx mask I get framing errors which I believe are caused > when the EvtChar is received. > > Is there currently a way with rxtx (I've using rxtx from Java) to > disable EV_RXFLAG? > > If not from Java, where would I start if I wanted to turn the EV_RXFLAG > option off in the C code? I've had a grep of the rxtx source code, but I > can't see where EV_RXFLAG is being set. > > Thanks in advance, > > AllenJB Hi Allen, I'd look at termios.c::tcsetattr() and termios.c::FillDCB() -- Trent Jarvi tjarvi at qbang.org From superdadusa at gmail.com Tue Aug 12 13:57:32 2008 From: superdadusa at gmail.com (John Choi) Date: Tue, 12 Aug 2008 13:57:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. Message-ID: Hi all, Just let you all know I just start to learn Java. I have download the serial comm package and the source code from open source communities.. I was able to verify with the given message string via serial monitor. when the given message string sends to the serial port then the character return added to the end of string by default if I use "Hello World" however if I changed to something else other than "Hello, World" there is no character return add to the end of string. I thing the library download from rxtx.org has implemented for the special strings. I can do like "login\n" in the string message to make character return but I don't want to add this individual custom character for each command return in every static message string I send, Can any who have done this might help me? Basically, something like this,, Write and add function to the program write a command, Reads the respond from a serial device.. Function handles multiple messages, Write: "com open" Read: Welcome to my world" expected Write: "admin" Read: Password?, expected Write: "admin" Read: you are successfully login terminal, expected. And I need to add a separate function handler handles a character return add to the each command above. If anyone can help this I can do the reset? Thank you in advance, John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0028.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SerialIO.java Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0028.pl From Steffen.DETTMER at ingenico.com Wed Aug 13 02:16:38 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 13 Aug 2008 10:16:38 +0200 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: References: Message-ID: <20080813081638.GA25412@elberon.bln.de.ingenico.com> * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > I can do like "login\n" in the string message to make character > return but I don't want to add this individual custom character > for each command return in every static message string I send, and why not?! > Can any who have done this might help me? what's about with writing a small wrapper function adding the carriage return? However, this would be slow, because either you call write two times (very bad) or the string needs to be copied, \n appended and written (since you are using Java Performance probably isn't so critical). Personally I would write `"login\n"' and `username + "\n"' etc., because since it is part of the command it should be part of the command definition string. > Basically, something like this,, Write and add function to the program write > a command, Reads the respond from a serial device.. correctly reading a `line' is more difficult. If you cannot make assumptions about timeouts and/or you need to have low delay, you need to read byte wise. If you need to save CPU resources you might need to add some buffering layer that you can read byte-wise but that is reading blockwise with some small timeout (lets say for serial lines something around byte transmission time times three or so). > /* > * To change this template, choose Tools | Templates > * and open the template in the editor. > */ :) > package joliba; > > /** > * > * @author root > */ :) > // derived from SUN's examples in the javax.comm package > import java.io.*; > import java.util.*; > //import javax.comm.*; // for SUN's serial/parallel port libraries > import gnu.io.*; // for rxtxSerial library > > public class SerialIO implements Runnable, SerialPortEventListener { > static CommPortIdentifier portId; > static CommPortIdentifier saveportId; > static Enumeration portList; > InputStream inputStream; > SerialPort serialPort; > Thread readThread; You need a thread for your synchronous RPC-style protocol? > static String messageString = "Hello, world!"; > static OutputStream outputStream; > static boolean outputBufferEmptyFlag = false; > > public static void main(String[] args) { > boolean portFound = false; > String defaultPort; > > // determine the name of the serial port on several operating systems > String osname = System.getProperty("os.name","").toLowerCase(); > if ( osname.startsWith("windows") ) { > // windows > defaultPort = "COM1"; > } else if (osname.startsWith("linux")) { > // linux > defaultPort = "/dev/ttyS0"; > } else if ( osname.startsWith("mac") ) { > // mac > defaultPort = "????"; > } else { > System.out.println("Sorry, your operating system is not supported"); > return; > } Is such a construction recommended? Isn't there some abstraction (like COM1 working on any platform)? [...] > try { > // activate the OUTPUT_BUFFER_EMPTY notifier > serialPort.notifyOnOutputEmpty(true); > } catch (Exception e) { > System.out.println("Error setting event notification"); > System.out.println(e.toString()); > System.exit(-1); > } I doubt that -1 is defined, probably some 127 or so would be the result, maybe better simply `throw e'? > public void writetoport() { > System.out.println("Writing \""+messageString+"\" to "+serialPort.getName()); > try { > // write string to serial port > outputStream.write(messageString.getBytes()); > } catch (IOException e) {} > } maybe something like /** * Writes the given output string and an additional carriage * return to the current outputStream. */ public void writeStringToPort( /** The output string (without CR). */ String output ) throws IOException { String outputLine = output + "\n"; outputStream.write(outputLine.getBytes()); } ? > > public SerialIO() { > // initalize serial port > try { > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > } catch (PortInUseException e) {} if the port is in use, you continue? Wonder that this works in Java, I would assume serialPort beeing uninitialized which AFAIK is an error in Java. > try { > inputStream = serialPort.getInputStream(); > } catch (IOException e) {} > > try { > serialPort.addEventListener(this); > } catch (TooManyListenersException e) {} > > // activate the DATA_AVAILABLE notifier > serialPort.notifyOnDataAvailable(true); > > try { > // set port parameters > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > } catch (UnsupportedCommOperationException e) {} > > // start the read thread > readThread = new Thread(this); > readThread.start(); > > } I think in all those exception cases you can abort, because it is unlikely that ignoring those errors allow a successful continuation, so in this case maybe it would be better to add a throw clause to the method. > public void run() { > // first thing in the thread, we initialize the write operation > initwritetoport(); > try { > while (true) { > // write string to port, the serialEvent will read it > writetoport(); > Thread.sleep(1000); > } > } catch (InterruptedException e) {} > } Does this make sense? Your `SimpleReadApp' writes one and the same string each second? > public void serialEvent(SerialPortEvent event) { > switch (event.getEventType()) { > case SerialPortEvent.BI: > case SerialPortEvent.OE: > case SerialPortEvent.FE: > case SerialPortEvent.PE: > case SerialPortEvent.CD: > case SerialPortEvent.CTS: > case SerialPortEvent.DSR: > case SerialPortEvent.RI: > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > break; > case SerialPortEvent.DATA_AVAILABLE: > // we get here if data has been received > byte[] readBuffer = new byte[20]; > try { > // read data > while (inputStream.available() > 0) { > int numBytes = inputStream.read(readBuffer); > } > // print data > String result = new String(readBuffer); > System.out.println("Read: "+result); > } catch (IOException e) {} I doubt that this is correct. I would assume you will get a 20 bytes result always, if more bytes would be available they would be printed in a second line but if less bytes are read I'd assume that the buffer/result contains zero bytes from implicite readBuffer contents initialisation (zero is no string terminator in Java AFAIK). > break; > } > } > } oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From florianmanschwetus at gmx.de Wed Aug 13 06:09:31 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 13 Aug 2008 14:09:31 +0200 Subject: [Rxtx] someone has seen such errors? Message-ID: <48A2CEFB.90007@gmx.de> I mean my communication mostly works, but it is far from perfect could this be the reason? Florian Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/949b9947/attachment-0028.bin From superdadusa at gmail.com Wed Aug 13 08:40:32 2008 From: superdadusa at gmail.com (John Choi) Date: Wed, 13 Aug 2008 08:40:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: <20080813081638.GA25412@elberon.bln.de.ingenico.com> References: <20080813081638.GA25412@elberon.bln.de.ingenico.com> Message-ID: Thank you so much Steffen and I will try that suggestion. John On 8/13/08, Steffen DETTMER wrote: > > * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > > I can do like "login\n" in the string message to make character > > return but I don't want to add this individual custom character > > for each command return in every static message string I send, > > and why not?! > > > Can any who have done this might help me? > > what's about with writing a small wrapper function adding the > carriage return? > However, this would be slow, because either you call write two > times (very bad) or the string needs to be copied, \n appended > and written (since you are using Java Performance probably isn't > so critical). > > Personally I would write `"login\n"' and `username + "\n"' etc., > because since it is part of the command it should be part of the > command definition string. > > > Basically, something like this,, Write and add function to the program > write > > a command, Reads the respond from a serial device.. > > correctly reading a `line' is more difficult. If you cannot make > assumptions about timeouts and/or you need to have low delay, you > need to read byte wise. If you need to save CPU resources you > might need to add some buffering layer that you can read > byte-wise but that is reading blockwise with some small timeout > (lets say for serial lines something around byte transmission > time times three or so). > > > /* > > * To change this template, choose Tools | Templates > > * and open the template in the editor. > > */ > > :) > > > package joliba; > > > > /** > > * > > * @author root > > */ > > :) > > > // derived from SUN's examples in the javax.comm package > > import java.io.*; > > import java.util.*; > > //import javax.comm.*; // for SUN's serial/parallel port libraries > > import gnu.io.*; // for rxtxSerial library > > > > public class SerialIO implements Runnable, SerialPortEventListener { > > static CommPortIdentifier portId; > > static CommPortIdentifier saveportId; > > static Enumeration portList; > > InputStream inputStream; > > SerialPort serialPort; > > Thread readThread; > > You need a thread for your synchronous RPC-style protocol? > > > static String messageString = "Hello, world!"; > > static OutputStream outputStream; > > static boolean outputBufferEmptyFlag = false; > > > > public static void main(String[] args) { > > boolean portFound = false; > > String defaultPort; > > > > // determine the name of the serial port on several operating > systems > > String osname = System.getProperty("os.name","").toLowerCase(); > > if ( osname.startsWith("windows") ) { > > // windows > > defaultPort = "COM1"; > > } else if (osname.startsWith("linux")) { > > // linux > > defaultPort = "/dev/ttyS0"; > > } else if ( osname.startsWith("mac") ) { > > // mac > > defaultPort = "????"; > > } else { > > System.out.println("Sorry, your operating system is not > supported"); > > return; > > } > > Is such a construction recommended? Isn't there some abstraction > (like COM1 working on any platform)? > > [...] > > try { > > // activate the OUTPUT_BUFFER_EMPTY notifier > > serialPort.notifyOnOutputEmpty(true); > > } catch (Exception e) { > > System.out.println("Error setting event notification"); > > System.out.println(e.toString()); > > System.exit(-1); > > } > > I doubt that -1 is defined, probably some 127 or so would be the > result, maybe better simply `throw e'? > > > public void writetoport() { > > System.out.println("Writing \""+messageString+"\" to > "+serialPort.getName()); > > try { > > // write string to serial port > > outputStream.write(messageString.getBytes()); > > } catch (IOException e) {} > > } > > maybe something like > > /** > * Writes the given output string and an additional carriage > * return to the current outputStream. > */ > public void > writeStringToPort( > /** The output string (without CR). */ > String output > ) throws IOException > { > String outputLine = output + "\n"; > outputStream.write(outputLine.getBytes()); > } > > ? > > > > > public SerialIO() { > > // initalize serial port > > try { > > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > > } catch (PortInUseException e) {} > > if the port is in use, you continue? Wonder that this works in > Java, I would assume serialPort beeing uninitialized which AFAIK > is an error in Java. > > > try { > > inputStream = serialPort.getInputStream(); > > } catch (IOException e) {} > > > > try { > > serialPort.addEventListener(this); > > } catch (TooManyListenersException e) {} > > > > // activate the DATA_AVAILABLE notifier > > serialPort.notifyOnDataAvailable(true); > > > > try { > > // set port parameters > > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > } catch (UnsupportedCommOperationException e) {} > > > > // start the read thread > > readThread = new Thread(this); > > readThread.start(); > > > > } > > I think in all those exception cases you can abort, because it is > unlikely that ignoring those errors allow a successful > continuation, so in this case maybe it would be better to add a > throw clause to the method. > > > public void run() { > > // first thing in the thread, we initialize the write operation > > initwritetoport(); > > try { > > while (true) { > > // write string to port, the serialEvent will read it > > writetoport(); > > Thread.sleep(1000); > > } > > } catch (InterruptedException e) {} > > } > > Does this make sense? Your `SimpleReadApp' writes one and the > same string each second? > > > public void serialEvent(SerialPortEvent event) { > > switch (event.getEventType()) { > > case SerialPortEvent.BI: > > case SerialPortEvent.OE: > > case SerialPortEvent.FE: > > case SerialPortEvent.PE: > > case SerialPortEvent.CD: > > case SerialPortEvent.CTS: > > case SerialPortEvent.DSR: > > case SerialPortEvent.RI: > > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > > break; > > case SerialPortEvent.DATA_AVAILABLE: > > // we get here if data has been received > > byte[] readBuffer = new byte[20]; > > try { > > // read data > > while (inputStream.available() > 0) { > > int numBytes = inputStream.read(readBuffer); > > } > > // print data > > String result = new String(readBuffer); > > System.out.println("Read: "+result); > > } catch (IOException e) {} > > I doubt that this is correct. I would assume you will get a 20 > bytes result always, if more bytes would be available they would > be printed in a second line but if less bytes are read I'd assume > that the buffer/result contains zero bytes from implicite > readBuffer contents initialisation (zero is no string terminator > in Java AFAIK). > > > break; > > } > > } > > } > > oki, > > Steffen > > About Ingenico Throughout the world businesses rely on Ingenico for secure > and expedient electronic transaction acceptance. Ingenico products leverage > proven technology, established standards and unparalleled ergonomics to > provide optimal reliability, versatility and usability. This comprehensive > range of products is complemented by a global array of services and > partnerships, enabling businesses in a number of vertical sectors to accept > transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged > information. If you are not the addressee or authorized to receive this for > the addressee, you must not use, copy, disclose or take any action based on > this message or any information herein. If you have received this message in > error, please advise the sender immediately by reply e-mail and delete this > message. Thank you for your cooperation. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/73c4135c/attachment-0027.html From ajmas at sympatico.ca Sat Aug 16 07:15:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 09:15:41 -0400 Subject: [Rxtx] someone has seen such errors? In-Reply-To: <48A2CEFB.90007@gmx.de> References: <48A2CEFB.90007@gmx.de> Message-ID: <43B5E8DA-1D93-4D90-809B-AAF35FF724C5@sympatico.ca> On 13-Aug-08, at 08:09 , Florian Manschwetus wrote: > I mean my communication mostly works, but it is far from perfect > could this be the reason? > > Florian > > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control Judging by the error messages this looks related to the driver you are using. Do a search for the following string with you favourite search engine, it should turn up a few hits: ftdi_set_termios FAILED to set databits/stopbits/parity Andre From ajmas at sympatico.ca Sat Aug 16 19:12:04 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 21:12:04 -0400 Subject: [Rxtx] Using SerialPortEvent? Message-ID: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Hi, Could someone tell me how I should be using the SerialPortEvent? Am I meant to be waiting for data and then simply reading from the inputstream? If this is the case why no just block on an inputstream read? Andr? From tjarvi at qbang.org Sat Aug 16 19:41:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 16 Aug 2008 19:41:13 -0600 (MDT) Subject: [Rxtx] Using SerialPortEvent? In-Reply-To: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> References: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Message-ID: On Sat, 16 Aug 2008, Andre-John Mas wrote: > Hi, > > Could someone tell me how I should be using the SerialPortEvent? Am I > meant to be waiting for data and then simply reading from the > inputstream? If this is the case why no just block on an inputstream > read? > Polling for data is fine also. It really depends upon what you are trying to do. For instance, if you require x bytes before reading, you can start polling after data is available. If you read on the same thread as your GUI and are waiting for data in a read, the results may be less than desirable. Java programming is 'usually' event driven rather than polling based. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sat Aug 16 20:10:39 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 22:10:39 -0400 Subject: [Rxtx] Using SerialPortEvent? In-Reply-To: References: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Message-ID: <3E495D4C-BB28-4845-A6AB-984C9A826BDF@sympatico.ca> On 16-Aug-08, at 21:41 , Trent Jarvi wrote: > On Sat, 16 Aug 2008, Andre-John Mas wrote: > >> Hi, >> >> Could someone tell me how I should be using the SerialPortEvent? Am I >> meant to be waiting for data and then simply reading from the >> inputstream? If this is the case why no just block on an inputstream >> read? >> > > Polling for data is fine also. It really depends upon what you are > trying to do. For instance, if you require x bytes before reading, > you can start polling after data is available. If you read on the > same thread as your GUI and are waiting for data in a read, the > results may be less than desirable. > > Java programming is 'usually' event driven rather than polling based. Sounds good. I thought I would use this opportunity to provide a event based version of the TwoWaySerialComm example. Could you just validate it before I add it to the Wiki: package ajmas74.experimental; import gnu.io.CommPort; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; import gnu.io.SerialPortEvent; import gnu.io.SerialPortEventListener; import java.io.IOException; import java.io.InputStream; import java.io.OutputStream; /** * This version of the TwoWaySerialComm example makes use of the * SerialPortEventListener to avoid polling. * * @author ajmas * */ public class TwoWaySerialComm { public TwoWaySerialComm() { super(); } void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { CommPort commPort = portIdentifier.open(this.getClass().getName(),2000); if ( commPort instanceof SerialPort ) { SerialPort serialPort = (SerialPort) commPort; serialPort .setSerialPortParams (57600 ,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); (new Thread(new SerialWriter(out))).start(); serialPort.addEventListener(new SerialReader(in)); } else { System.out.println("Error: Only serial ports are handled by this example."); } } } /** * Handles the input coming from the serial port. A new line character * is treated as the end of a block in this example. */ public static class SerialReader implements SerialPortEventListener { private InputStream in; private byte[] buffer = new byte[1024]; public SerialReader ( InputStream in ) { this.in = in; } public void serialEvent(SerialPortEvent arg0) { int data; try { int len = 0; while ( ( data = in.read()) > -1 ) { if ( data != '\n' ) { break; } buffer[len++] = (byte) data; } System.out.print(new String(buffer,0,len)); } catch ( IOException e ) { e.printStackTrace(); System.exit(-1); } } } /** */ public static class SerialWriter implements Runnable { OutputStream out; public SerialWriter ( OutputStream out ) { this.out = out; } public void run () { try { int c = 0; while ( ( c = System.in.read()) > -1 ) { this.out.write(c); } } catch ( IOException e ) { e.printStackTrace(); System.exit(-1); } } } public static void main ( String[] args ) { try { (new TwoWaySerialComm()).connect("COM3"); } catch ( Exception e ) { e.printStackTrace(); } } } From lfarkas at lfarkas.org Tue Aug 19 07:32:59 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Tue, 19 Aug 2008 15:32:59 +0200 Subject: [Rxtx] JNI or CNI Message-ID: <48AACB8B.9060606@lfarkas.org> hi, what is the current recommended way to rxtx on linux JNI or it's better to use CNI? is the CNI version fully functional and the same level as the JNI? i currently try to make a rhel/centos/fedora rpm for rxtx but has many problems with the standard dir structure. yours. -- Levente "Si vis pacem para bellum!" From lfarkas at lfarkas.org Tue Aug 19 08:47:34 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Tue, 19 Aug 2008 16:47:34 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel Message-ID: <48AADD06.7040809@lfarkas.org> hi, newer or not so newer linux kernel do not contain the UTS_RELEASE so the current rxtx is not compile on the latest kernels. even if it's commented out in the cvs configure there are other places. i attcahed a patch which fix it (or at least doesn't cause error at non-debug build). ps. is there any plan to the new 2.1-8 release in the near future? there are many changes (at least the license change in all file and in this case create a diff is very difficult)? the latest release more then 2 years old:-( -- Levente "Si vis pacem para bellum!" -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-2.1-uts.patch Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080819/ab5d38ac/attachment-0021.pl From ajmas at sympatico.ca Tue Aug 19 16:21:53 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 19 Aug 2008 18:21:53 -0400 Subject: [Rxtx] Event based example Message-ID: <24735BFB-B088-4B84-8173-FE98DF63B12F@sympatico.ca> Hi, I have just posted an example of using SerialPortEventListener in the Wiki: http://rxtx.qbang.org/wiki/index.php/Event_Based_Two_Way_Communication If you see any issues please could you let me know, or makes the changes. Andre From Martin.Oberhuber at windriver.com Fri Aug 22 04:02:24 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 22 Aug 2008 12:02:24 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <48AADD06.7040809@lfarkas.org> References: <48AADD06.7040809@lfarkas.org> Message-ID: <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> Farkas, there are indeed efforts to get a new RXTX release out the door. Your experience as a package maintainer would likely be helpful during these efforts, since I'd think it makes sense to keep the patches minimal that you must make to have the source compile in your environment. What are the things that you find problematic, apart from the UTS thing that you have mentioned before? What is the timing that you have in mind for your package? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Farkas Levente > Sent: Tuesday, August 19, 2008 4:48 PM > To: rxtx at qbang.org > Subject: [Rxtx] UTS_RELEASE not defined in newer kernel > > hi, > newer or not so newer linux kernel do not contain the > UTS_RELEASE so the > current rxtx is not compile on the latest kernels. even if it's > commented out in the cvs configure there are other places. > i attcahed a patch which fix it (or at least doesn't cause error at > non-debug build). > > ps. is there any plan to the new 2.1-8 release in the near > future? there > are many changes (at least the license change in all file and in this > case create a diff is very difficult)? the latest release more then 2 > years old:-( > > -- > Levente "Si vis pacem para bellum!" > From lfarkas at lfarkas.org Fri Aug 22 04:36:26 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Fri, 22 Aug 2008 12:36:26 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> References: <48AADD06.7040809@lfarkas.org> <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> Message-ID: <48AE96AA.6090505@lfarkas.org> hi, the packages already build for fedora-9 and centos-5 and here: http://www.lfarkas.org/linux/packages/ what i've to patch, the UTS, the configure script, but it's already fixed in the cvs (in another way) and the loadlibrary. the reasons for last one can be found here: https://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_files_that_use_JNI after we test it i'd like to add these packages to fedora and epel main repository (that's why it's be useful a new release after 2 years:-) imho versions are cheap and why not just release 2.1-8? the real code changes are minimal and if something critical bug found still can release 2.1-9:-) ps. and would be better to use simple number for version like 2.1-7 rather then 2.1-7v2. Oberhuber, Martin wrote: > Farkas, > > there are indeed efforts to get a new RXTX release out the > door. Your experience as a package maintainer would likely > be helpful during these efforts, since I'd think it makes > sense to keep the patches minimal that you must make to > have the source compile in your environment. > > What are the things that you find problematic, apart from > the UTS thing that you have mentioned before? > > What is the timing that you have in mind for your package? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >> On Behalf Of Farkas Levente >> Sent: Tuesday, August 19, 2008 4:48 PM >> To: rxtx at qbang.org >> Subject: [Rxtx] UTS_RELEASE not defined in newer kernel >> >> hi, >> newer or not so newer linux kernel do not contain the >> UTS_RELEASE so the >> current rxtx is not compile on the latest kernels. even if it's >> commented out in the cvs configure there are other places. >> i attcahed a patch which fix it (or at least doesn't cause error at >> non-debug build). >> >> ps. is there any plan to the new 2.1-8 release in the near >> future? there >> are many changes (at least the license change in all file and in this >> case create a diff is very difficult)? the latest release more then 2 >> years old:-( >> >> -- >> Levente "Si vis pacem para bellum!" >> -- Levente "Si vis pacem para bellum!" From tjarvi at qbang.org Fri Aug 22 18:50:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Aug 2008 18:50:32 -0600 (MDT) Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <48AE96AA.6090505@lfarkas.org> References: <48AADD06.7040809@lfarkas.org> <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> <48AE96AA.6090505@lfarkas.org> Message-ID: Hi Farkas, The v2 was simply the second build - no code changes. We are comming out with a new release shortly. I would encourage working with distros as you are. The building of rxtx turns out to be a bottle neck in quick releases. We do want stable releases that work for a year or more but I would have no problems with quicker cycles on developing work. I would have no problem working with someone that did builds that receive less testing more often but they do have to come out for multiple platforms from this end. Thanks for the links. On Fri, 22 Aug 2008, Farkas Levente wrote: > hi, > the packages already build for fedora-9 and centos-5 and here: > http://www.lfarkas.org/linux/packages/ > what i've to patch, the UTS, the configure script, but it's already > fixed in the cvs (in another way) and the loadlibrary. the reasons for > last one can be found here: > https://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_files_that_use_JNI > after we test it i'd like to add these packages to fedora and epel main > repository (that's why it's be useful a new release after 2 years:-) > imho versions are cheap and why not just release 2.1-8? the real code > changes are minimal and if something critical bug found still can > release 2.1-9:-) > > ps. and would be better to use simple number for version like 2.1-7 > rather then 2.1-7v2. > > Oberhuber, Martin wrote: >> Farkas, >> >> there are indeed efforts to get a new RXTX release out the >> door. Your experience as a package maintainer would likely >> be helpful during these efforts, since I'd think it makes >> sense to keep the patches minimal that you must make to >> have the source compile in your environment. >> >> What are the things that you find problematic, apart from >> the UTS thing that you have mentioned before? >> >> What is the timing that you have in mind for your package? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >>> On Behalf Of Farkas Levente >>> Sent: Tuesday, August 19, 2008 4:48 PM >>> To: rxtx at qbang.org >>> Subject: [Rxtx] UTS_RELEASE not defined in newer kernel >>> >>> hi, >>> newer or not so newer linux kernel do not contain the >>> UTS_RELEASE so the >>> current rxtx is not compile on the latest kernels. even if it's >>> commented out in the cvs configure there are other places. >>> i attcahed a patch which fix it (or at least doesn't cause error at >>> non-debug build). >>> >>> ps. is there any plan to the new 2.1-8 release in the near >>> future? there >>> are many changes (at least the license change in all file and in this >>> case create a diff is very difficult)? the latest release more then 2 >>> years old:-( >>> >>> -- >>> Levente "Si vis pacem para bellum!" >>> > > > From andy at triera.net Sat Aug 23 15:17:44 2008 From: andy at triera.net (Andy Rozman) Date: Sat, 23 Aug 2008 21:17:44 +0000 Subject: [Rxtx] port not identified on FreeBSD In-Reply-To: References: Message-ID: <48B07E78.2030306@triera.net> Hi ! I have one small problem... I have started using FreeBSD in last few days and I have come accross a problem with rxtx on FreeBSD. I am using usb-to-serial converter, which is identified under FreeBSD without problem as ucom0, and creates link under /dev called ttyU0, which is correct way to be done under FreeBSD (if device would be unidentified it would be called ugen0 - as usb generic). Problem is that I say to rxtx to get my all serial ports this one is not among them. Which names are permissable under linux-like implementations? Which will be accepted as serial ports? Andy From tjarvi at qbang.org Sat Aug 23 13:57:45 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 23 Aug 2008 13:57:45 -0600 (MDT) Subject: [Rxtx] port not identified on FreeBSD In-Reply-To: <48B07E78.2030306@triera.net> References: <48B07E78.2030306@triera.net> Message-ID: On Sat, 23 Aug 2008, Andy Rozman wrote: > Hi ! > > I have one small problem... I have started using FreeBSD in last few > days and I have come accross a problem with rxtx on FreeBSD. > > I am using usb-to-serial converter, which is identified under FreeBSD > without problem as ucom0, and creates link under /dev called > ttyU0, which is correct way to be done under FreeBSD (if device would be > unidentified it would be called ugen0 - as usb generic). Problem is that > I say to rxtx to get my all serial ports this one is not among them. > Which names are permissable under linux-like implementations? Which will > be accepted as serial ports? > > Andy > Thanks Andy! We will add ttyU* to FreeBSD. For now you can use properties to enable the port. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting#How_does_rxtx_detect_ports.3F__Can_I_override_it.3F The fix: diff -u -r1.16.2.59 RXTXCommDriver.java --- RXTXCommDriver.java 18 Nov 2007 22:32:41 -0000 1.16.2.59 +++ RXTXCommDriver.java 23 Aug 2008 19:55:25 -0000 @@ -644,6 +644,7 @@ { String[] Temp = { "ttyd", //general purpose serial ports + "ttyU", //general purpose USB serial ports "cuaa", //dialout serial ports "ttyA", //Specialix SI/XIO dialin ports "cuaA", //Specialix SI/XIO dialout ports -- Trent Jarvi tjarvi at qbang.org From rick_knight at rlknight.com Mon Aug 4 13:25:10 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Mon, 04 Aug 2008 12:25:10 -0700 Subject: [Rxtx] Sun's Comm API? Message-ID: <48975796.4010600@rlknight.com> I have an application that requires the javax compatible version of RXTX and Sun's comm api. I've been able to download and extract the version of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api anywhere. Can someone tell me where I can find it? Or maybe send me a copy? Also, when I try to build RXTX, configure and make complete successfully but make install failes with this error libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 I've never come accross this error before. How can I get past it? Thanks, Rick From bboyes at systronix.com Mon Aug 4 19:10:01 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:10:01 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48975796.4010600@rlknight.com> References: <48975796.4010600@rlknight.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/cb9c6167/attachment-0037.html From bboyes at systronix.com Mon Aug 4 19:12:37 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:12:37 -0600 Subject: [Rxtx] Towards an RXTX release - CSR BT/USB chipset In-Reply-To: <488FB7E7.8000802@gmail.com> References: <460801A4097E3D4CA04CC64EE648584806C56CF0@ism-mail03.corp.ad.wrs.com> <13557-75390@sneakemail.com> <20980-23424@sneakemail.com> <488FB7E7.8000802@gmail.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/52236088/attachment-0037.html From tjarvi at qbang.org Mon Aug 4 19:42:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 19:42:21 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: On Mon, 4 Aug 2008, Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: > I have an application that requires the javax compatible > version of RXTX > and Sun's comm api. I've been able to download and extract > the version > of RXTX that I need (2.0-7pre2) but I can't find Sun's camm > api > anywhere. Can someone tell me where I can find it? Or maybe > send me a > > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm port > support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have just > a ZIP with only the .class JAR file - no source or docs), has a readme > with these comments: > > This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release.? The 2.0.3 release itself is > no longer distributed.? comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project.? The RxTx project (http://www.rxtx.org ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org) was opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support.? Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins.? Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > ? > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > I hope that is helpful! > It would be nice to work with Sun to resolve those longstanding issues. But it may not be practical unless the process goes as fast and painless as the grandfathering of commapi did. Another option may be the old kaffe extensions that moved to gnu classpathx. These don't have the native libraries but should provide the 2.0 interface and the javax.comm.properties mechansim for SPI. http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Mon Aug 4 20:23:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Mon, 04 Aug 2008 20:23:57 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4897B9BD.5070809@ergotech.com> Has there been any work/would it be possible, to layer a javacomm look-alike on top of the GNU code? The goal is not to move the javax code forward, but to emulate the "legacy" javax packages for people who still need this. Jim Trent Jarvi wrote: > On Mon, 4 Aug 2008, Bruce Boyes wrote: > >> At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible >> version of RXTX >> and Sun's comm api. I've been able to download and extract >> the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm >> api >> anywhere. Can someone tell me where I can find it? Or maybe >> send me a >> >> >> javaxcomm has had a sort of on-again off-again history. The windoze >> version has been languishing for years (literally) but there are newer >> versions for other OS's. >> >> We try to keep links on one of our help pages current: >> http://www.practicalembeddedjava.com/tools/javatools_list.html >> which gets you to here: >> http://java.sun.com/products/javacomm/ >> where it says in fact they no longer even support Windows and Mac: >> "Implementations of the API are currently available for Solaris SPARC, >> Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so >> someone could support it. But I guess that's part of the reason RXTX >> exists! >> >> So one of Sun's own products, SunSPOT, has to use RXTX to get comm port >> support. >> >> The version we use is 2.0 from 11/15/1998. I have posted it on our >> website, which is within the terms of the license agreement contained >> therein (as I understand it). >> >> The last version of javaxcomm for Windows, 2.0.3, (for which I have just >> a ZIP with only the .class JAR file - no source or docs), has a readme >> with these comments: >> >> This distribution contains the comm.jar file original part >> of the COMMAPI 2.0.3 release. The 2.0.3 release itself is >> no longer distributed. comm.jar, which contains the comm >> API java class files (eg. Sun's binary implementation of the >> interface classes), is being made available, unsupported, >> with no obligation to fix bugs, at the request of the RXTX >> project. The RxTx project (http://www.rxtx.org ), uses the >> comm.jar class files, but provides their own native library >> components to provide support for other platforms. >> >> The 2.0.3 comm.jar is being provided in this way because >> as of COMMAPI 3.x, the java binary implementation forked and >> became incompatible with the RxTx project's native code. >> Due to the lack of a clear business case, and to resource >> constraints, no additional resources are being >> provided to provide an alternative engineering solution >> at the time of writing. >> >> RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: >> >> Ultimately the COMMAPI would be better served if a Java >> Community Process JSR (http://www.jcp.org) was opened and >> the COMMAPI was rearchitected to provide a more pluggable >> framework to improve cross-platform support. Such an >> architecture would embody a better defined and better >> documented SPI interface, including a way for comm. ports >> to be revealed to the client application through the API >> via platform-aware plugins. Similarly, native code used >> to access comm port in general could be handled more >> flexibly using a plugin model, whereby on any platform, >> multiple native modules could be in use simultaneously. >> >> Since there are now various ways serial ports can be implemented >> and accessed, modular comm. port JNI native libraries would be >> of benefit insofar as removing the burden of over-generalization >> from any single native component, or inversely, by relieving the >> implicit constraint that comm. drivers be accessed only via a >> monolithic mechanism, such as the UNIX vnode interface. >> >> paul.klissner at sun.com >> 6/10/06 >> >> I hope that is helpful! >> > > It would be nice to work with Sun to resolve those longstanding issues. > But it may not be practical unless the process goes as fast and painless > as the grandfathering of commapi did. > > Another option may be the old kaffe extensions that moved to gnu > classpathx. These don't have the native libraries but should provide > the 2.0 interface and the javax.comm.properties mechansim for SPI. > > http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Mon Aug 4 21:09:15 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 21:09:15 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? Message-ID: Hi Jim, I will not step into the javax.comm namespace without Sun's explicite permission. I fully understand the pain point you are trying to address. In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm Linux) - which remains an integral part of rxtx. At the time it was a win for Sun and rxtx. The Sun commapi license is/was fairly clear that rxtx should not step into that namespace. It made sense as Sun was active in that space and rxtx may go into another namespace - it was an experiment in working with Sun. This may sound silly looking at something that happened almost 10 years ago. In a community of respect which Sun helped create, there is no question about what to do. I hope eventually Sun will step up and do a right thing too. I agree that this is hurting the API more than helping it. There are also questions about how to replace the API in the long term which includes HID support which isn't going well so far. Others that can't even look at Sun's javax.comm today and can look at Kaffe's contribution to classpathx can easily work around such restrictions. On Mon, 4 Aug 2008, Jim Redman wrote: > Has there been any work/would it be possible, to layer a javacomm > look-alike on top of the GNU code? > > The goal is not to move the javax code forward, but to emulate the > "legacy" javax packages for people who still need this. > > Jim > > Trent Jarvi wrote: >> >> It would be nice to work with Sun to resolve those longstanding issues. >> But it may not be practical unless the process goes as fast and painless >> as the grandfathering of commapi did. >> >> Another option may be the old kaffe extensions that moved to gnu >> classpathx. These don't have the native libraries but should provide >> the 2.0 interface and the javax.comm.properties mechansim for SPI. >> >> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From florianmanschwetus at gmx.de Tue Aug 5 05:04:46 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 13:04:46 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: References: <48971C1F.9020806@gmx.de> Message-ID: <489833CE.1040801@gmx.de> Just look at sendCommand in this method I have to place a Thread.sleep(20) after each byte send to get working. Even the event based receive doesn't work fine but this could be may stupidness. The specifikation document (it is on the last pages of the manual) for the beamer could be found on: http://www.optoma.co.uk/support.aspx Florian Manschwetus Trent Jarvi schrieb: > > Hi Florian > > Sorry for the top post in advance. I worry you may not see my answer > under all your code :) > > I have not received this email before. This is 500k of code which I > don't have time to read. I can spend about 5 min on each hobby email > and still get to work in the morning. I have a couple suggestions for > how to get an answer. > > First, cut out your comments and extra code so you can demonstrate the > question (I might even glance and see what is wrong then). Don't go for > a working final product. Isolate the problem using a simple program and > then ask with that as an example. If I did what you just did, I'd have > to post 3/4 of a million lines of code :) > > Second, join the rxtx mail-list and ask there. This will give you 100x > more eyes. I'll also read and try to follow. > > -- > taj > > > > On Mon, 4 Aug 2008, Florian Manschwetus wrote: > >> It could be that my university account is blocked by filters so >> resending from here. >> >> >> Topic is to control Optoma HD80 beamer using rs232 serial chat. >> This code is able to detect power state and switch the beamer on / off. >> connected is the beamer using a digitus usb 2.0 serial adapter with an >> FT232 USB-Serial adapter the systems architecture is amd64. >> >> Please take a look in the sendCommand routine i have to place theire >> those Thread.sleep to get it working. >> Now the question is this correct or is there a better way to get this >> working correctly? >> >> In the javadoc coming with the install i found this: >> setBaudBase >> >> public boolean setBaudBase(int BaudBase) >> throws UnsupportedCommOperationException, >> java.io.IOException >> >> Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 >> before using. >> >> could this explain the error? >> I attached my java source and the protocol description for the beamer >> (available on vendor website). >> >> thx, >> Florian Manschwetus >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: TestRS232.java Type: text/x-java Size: 9143 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0074.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0075.bin From michael.erskine at ketech.com Tue Aug 5 05:53:49 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Tue, 5 Aug 2008 12:53:49 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489833CE.1040801@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> > Just look at sendCommand in this method I have to place a > Thread.sleep(20) after each byte send to get working. Even the event > based receive doesn't work fine but this could be may stupidness. Hi Florian, Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. Regards, Michael Erskine. From florianmanschwetus at gmx.de Tue Aug 5 07:28:15 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:28:15 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> Message-ID: <4898556F.8000208@gmx.de> Michael Erskine schrieb: >> Just look at sendCommand in this method I have to place a >> Thread.sleep(20) after each byte send to get working. Even the event >> based receive doesn't work fine but this could be may stupidness. > > Hi Florian, > > Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. > > Regards, > Michael Erskine. > Ok, sounds fine for the receiving problem. But why i have to wait after each byte when sending a command squence? (the for loop in send command) Florian > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/284f350c/attachment-0036.bin From florianmanschwetus at gmx.de Tue Aug 5 07:44:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:44:14 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <4898592E.2020908@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >>> Just look at sendCommand in this method I have to place a >>> Thread.sleep(20) after each byte send to get working. Even the event >>> based receive doesn't work fine but this could be may stupidness. >> >> Hi Florian, >> >> Yes, naturally you'll have to wait for a response from the other end. >> Why not wait for notification from the event thread perhaps using a >> BlockingDeque rather than your LinkedList. Generally I >> try to decouple all input and output streams: in your case your >> application is operating synchronously like the "expect" program >> (http://expect.nist.gov/) so waits (or timeouts) will need to be >> factored in. >> >> Regards, >> Michael Erskine. >> > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) > > Florian Furthermore there is this basic baud with this confusing javadoc entry: public boolean setBaudBase(int BaudBase) throws UnsupportedCommOperationException, java.io.IOException Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 before using. maybe this could explain something Florian >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/006c7425/attachment-0036.bin From jredman at ergotech.com Tue Aug 5 09:13:36 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 05 Aug 2008 09:13:36 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: Message-ID: <48986E20.3060104@ergotech.com> Trent, So two issues: 1) Technically I'm still not sure how easy/practical a layer would be. The problems are always classes like listeners, and wrapping returns of gnu.io classes. I really see it as a "delegate" type of concept. Any thoughts or ideas of the practicality of this approach? The idea is not to modify RXTX. 2) Javax. The javax namespace does seem to be in widespread use outside of Sun (the same is true for the java namespace). The classpath extensions, or some other location, should be interested in a JavaComm implementation even if it does have dependencies on RXTX. Would you have any philosophical objection to an approach like that? Of course, I suspect it might be better if someone with that authority at Sun would admit that the javax namespace is already in the wild and that there is no problem with it being used within RXTX. Jim Trent Jarvi wrote: > Hi Jim, > > I will not step into the javax.comm namespace without Sun's explicite > permission. I fully understand the pain point you are trying to address. > > In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm > Linux) - which remains an integral part of rxtx. At the time it was a win for > Sun and rxtx. > > The Sun commapi license is/was fairly clear that rxtx should not step into that > namespace. It made sense as Sun was active in that space and rxtx may go into > another namespace - it was an experiment in working with Sun. > > This may sound silly looking at something that happened almost 10 years ago. > In a community of respect which Sun helped create, there is no question about > what to do. I hope eventually Sun will step up and do a right thing too. > > I agree that this is hurting the API more than helping it. There are also > questions about how to replace the API in the long term which includes HID > support which isn't going well so far. > > Others that can't even look at Sun's javax.comm today and can look at Kaffe's > contribution to classpathx can easily work around such restrictions. > > On Mon, 4 Aug 2008, Jim Redman wrote: > >> Has there been any work/would it be possible, to layer a javacomm >> look-alike on top of the GNU code? >> >> The goal is not to move the javax code forward, but to emulate the >> "legacy" javax packages for people who still need this. >> >> Jim >> >> Trent Jarvi wrote: >>> It would be nice to work with Sun to resolve those longstanding issues. >>> But it may not be practical unless the process goes as fast and painless >>> as the grandfathering of commapi did. >>> >>> Another option may be the old kaffe extensions that moved to gnu >>> classpathx. These don't have the native libraries but should provide >>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>> >>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From sandeep at genevasoftech.com Tue Aug 5 11:18:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Tue, 05 Aug 2008 22:48:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <48988B6C.5080409@genevasoftech.com> Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. *-- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/ad20f1cb/attachment-0036.html From Martin.Oberhuber at windriver.com Tue Aug 5 13:30:17 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Tue, 5 Aug 2008 21:30:17 +0200 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Sandeep, shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on Sol7 but I've successfully run it on Sol9 and Sol10. Or is your request really about a native 64bit variant? I'm afraid that then you're out of luck since I think that quite a bit of RXTX is not yet ready for 64 bit. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Sandeep Kumar K Sent: Tuesday, August 05, 2008 7:19 PM To: rxtx at qbang.org Subject: [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so for Solaris 9 Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. -- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/81b7f988/attachment-0036.html From tjarvi at qbang.org Tue Aug 5 22:38:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 22:38:34 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 5 Aug 2008, Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built > on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid that > then > you're out of luck since I think that quite a bit of RXTX is not yet > ready > for 64 bit. > While rxtx-2.1-7 probably has problems, The CVS code should be OK for 64 bit Solaris. If it isn't, let me know and I'll find which patch is missing. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Aug 5 23:13:00 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 23:13:00 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48986E20.3060104@ergotech.com> References: <48986E20.3060104@ergotech.com> Message-ID: On Tue, 5 Aug 2008, Jim Redman wrote: > Trent, > > So two issues: > > 1) Technically I'm still not sure how easy/practical a layer would be. The > problems are always classes like listeners, and wrapping returns of gnu.io > classes. I really see it as a "delegate" type of concept. Any thoughts or > ideas of the practicality of this approach? The idea is not to modify RXTX. I have not put too much thought into this. I assume you want what rxtx 2.0 provided to tie into javax.comm implementations. More classes could be added to rxtx 2.1-7 for SPI support. Maintaining rxtx-2.0 could also be handed to someone if they like. > > 2) Javax. The javax namespace does seem to be in widespread use outside of > Sun (the same is true for the java namespace). The classpath extensions, or > some other location, should be interested in a JavaComm implementation even > if it does have dependencies on RXTX. Would you have any philosophical > objection to an approach like that? > No problems. Classpathx would be a possible place to do it. I'd suggest thinking twice about what this involves in practical terms. You would be wanting to revive the 2.0 API while Sun is at 3.0 and grandfathering the JSR. This undermines the main reason (established api) for using the javax.comm namespace and does not leave such a project in a good position. The only win I see here is maintaining support for applications that can't migrate namespaces. Not that that isn't important. At some point it is going to be less work to just edit the bytecode :) Such a javax.comm effort would also be signing up new projects that decided to use the work up for concerns they probably will not understand or expect. That probably isn't a good path to facilitate for new projects at this time. We will put a good faith effort to work well with others but keep in mind the project has limited bandwidth for such efforts. > Of course, I suspect it might be better if someone with that authority at Sun > would admit that the javax namespace is already in the wild and that there is > no problem with it being used within RXTX. > > Jim > > Trent Jarvi wrote: >> Hi Jim, >> >> I will not step into the javax.comm namespace without Sun's explicite >> permission. I fully understand the pain point you are trying to address. >> >> In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java >> Comm Linux) - which remains an integral part of rxtx. At the time it was a >> win for Sun and rxtx. >> >> The Sun commapi license is/was fairly clear that rxtx should not step into >> that namespace. It made sense as Sun was active in that space and rxtx may >> go into another namespace - it was an experiment in working with Sun. >> >> This may sound silly looking at something that happened almost 10 years >> ago. In a community of respect which Sun helped create, there is no >> question about what to do. I hope eventually Sun will step up and do a >> right thing too. >> >> I agree that this is hurting the API more than helping it. There are also >> questions about how to replace the API in the long term which includes HID >> support which isn't going well so far. >> >> Others that can't even look at Sun's javax.comm today and can look at >> Kaffe's contribution to classpathx can easily work around such >> restrictions. >> >> On Mon, 4 Aug 2008, Jim Redman wrote: >> >>> Has there been any work/would it be possible, to layer a javacomm >>> look-alike on top of the GNU code? >>> >>> The goal is not to move the javax code forward, but to emulate the >>> "legacy" javax packages for people who still need this. >>> >>> Jim >>> >>> Trent Jarvi wrote: >>>> It would be nice to work with Sun to resolve those longstanding issues. >>>> But it may not be practical unless the process goes as fast and painless >>>> as the grandfathering of commapi did. >>>> >>>> Another option may be the old kaffe extensions that moved to gnu >>>> classpathx. These don't have the native libraries but should provide >>>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>>> >>>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From sandeep at genevasoftech.com Wed Aug 6 00:03:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Wed, 06 Aug 2008 11:33:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: <48993EB8.30107@genevasoftech.com> Thank you Mr. Martin for your suggestion. The native file which is given in rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am getting the following error . Any suggestions to solve this issue. I am using Solaris SPARC 64 bit machine. ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) thrown while loading gnu.io.RXTXCommDriver Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(Unknown Source) at java.lang.ClassLoader.loadLibrary(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) at com.ReadFromModem.main(ReadFromModem.java:84) * * *Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid > that then > you're out of luck since I think that quite a bit of RXTX is not yet ready > for 64 bit. > > Cheers, > -- > *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > ------------------------------------------------------------------------ > *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On > Behalf Of *Sandeep Kumar K > *Sent:* Tuesday, August 05, 2008 7:19 PM > *To:* rxtx at qbang.org > *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so > for Solaris 9 > > Hi, > > Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 > bit machine. The librxtxSerial.so given in website is for Solaris 8. > > *-- > > Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/1e920343/attachment-0036.html From tjarvi at qbang.org Wed Aug 6 00:21:42 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 00:21:42 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <48993EB8.30107@genevasoftech.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> <48993EB8.30107@genevasoftech.com> Message-ID: Hi Sandeep You may be out of luck unless you can compile the 2.1 src in CVS (requires gnu make and gcc). But you could try the ToyBox(R)(TM) which is a collection of WiLdLy untested cross compiled 2.1-7 binaries covering everything from the ibm z series to embeded arm/ppc. To give an idea how poorly these are tested, I don't even know if z series machines have a serial port. ftp://www.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Solaris They should at least match the binary types. Actually, I think if you use the rxtx jar from CVS with that file, it should 'work' as the fix for 64 bits was in java not the native code. You could just cd rxtx*/src; javac *.java then jar -cf RXTXcomm.jar `find -name \*.class` to create the hybrid which will complain about version information a bit. On Wed, 6 Aug 2008, Sandeep Kumar K wrote: > Thank you Mr. Martin for your suggestion. The native file which is given in > rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am > getting the following error . > Any suggestions to solve this issue. > I am using Solaris SPARC 64 bit machine. > > ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar > java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 > (Possible cause: architecture word > width mismatch) thrown while loading gnu.io.RXTXCommDriver > Exception in thread "main" java.lang.UnsatisfiedLinkError: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF > class: ELFCLASS64 (Possible cause: > architecture word width mismatch) > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(Unknown Source) > at java.lang.ClassLoader.loadLibrary(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > at com.ReadFromModem.main(ReadFromModem.java:84) > > * > * > > *Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > > > Oberhuber, Martin wrote: >> Sandeep, >> shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse >> variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on >> Sol7 but I've successfully run it on Sol9 and Sol10. >> Or is your request really about a native 64bit variant? I'm afraid that >> then >> you're out of luck since I think that quite a bit of RXTX is not yet ready >> for 64 bit. >> Cheers, >> -- >> *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> ------------------------------------------------------------------------ >> *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On >> Behalf Of *Sandeep Kumar K >> *Sent:* Tuesday, August 05, 2008 7:19 PM >> *To:* rxtx at qbang.org >> *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so >> for Solaris 9 >> >> Hi, >> >> Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 >> bit machine. The librxtxSerial.so given in website is for Solaris 8. >> >> *-- >> Thanks & Regards >> >> Sandeep Kumar K >> Sr. Software Engineer >> Geneva Software Technologies >> Whitefield, Bangalore >> Mob : 9880193454* >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> From michael.erskine at ketech.com Wed Aug 6 01:39:28 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 6 Aug 2008 08:39:28 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Florian Manschwetus wrote: > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) Hi Florian, I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. Regards, Michael Erskine. From florianmanschwetus at gmx.de Wed Aug 6 02:53:16 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 06 Aug 2008 10:53:16 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Message-ID: <4899667C.6010706@gmx.de> Michael Erskine schrieb: > Florian Manschwetus wrote: >> Ok, sounds fine for the receiving problem. >> But why i have to wait after each byte when sending a command squence? >> (the for loop in send command) > > Hi Florian, > I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. > > Regards, > Michael Erskine. > correct with a terminal on the other end it works, my idea was that this basic baud has some influence. Could some one explain what it is for? Florian > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/c2b4fa84/attachment-0036.bin From rick_knight at rlknight.com Wed Aug 6 13:01:07 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:01:07 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F4F3.3020707@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > I have an application (Readerware) that uses RXTX with Javax to access the serial port. This used to work fine under previous Linux' and Java, but something has changed, I assume with Java itself , that is causing the application to fail with a link error. The application is not able to find librxtxSerialParallel.so. RXTX supplies librxtxSerial.so and librxtxParallel.so, but not librxtxSerialParallel.so. Where can I get librxtxSerialParallel.so, or do I need it? Is something else causing the lib to not be found? Thanks, Rick Knight From rick_knight at rlknight.com Wed Aug 6 13:17:55 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:17:55 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F8E3.5060400@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Thanks for the reply. The developer of the app I'm trying to use (Readerware) has sent me a copy of the comm.api and I've copied the library (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar into the proper places. When I try to run the application, I get this error... Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: /usr/lib/libSolarisSerialParallel.so: /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not little-endian (Possible cause: endianness mismatch) Caught java.lang.UnsatisfiedLinkError: com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I while loading driver com.sun.comm.SolarisDriver Is there a way around this error? Thanks again, Rick Knight From jlar310 at gmail.com Wed Aug 6 13:37:42 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 14:37:42 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899F8E3.5060400@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > The developer of the app I'm trying to use (Readerware) has sent me a > copy of the comm.api and I've copied the library > (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar > into the proper places. When I try to run the application, I get this > error... > > Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: > /usr/lib/libSolarisSerialParallel.so: > /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not > little-endian (Possible cause: endianness mismatch) > Caught java.lang.UnsatisfiedLinkError: > com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I > > while loading driver com.sun.comm.SolarisDriver > > Is there a way around this error? What host OS are you running? From your original post it looks like 32 bit Linux. The libSolarisSerialParallel.so file is for Sun Solaris and will vary depending on the underlying hardware architecture as well. Sorry for the double post Rick, but I failed to send this to the list the first time... -- Jeff From rick_knight at rlknight.com Wed Aug 6 13:44:29 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:44:29 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: <4899FF1D.9030504@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > > >> The developer of the app I'm trying to use (Readerware) has sent me a >> copy of the comm.api and I've copied the library >> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >> into the proper places. When I try to run the application, I get this >> error... >> >> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >> /usr/lib/libSolarisSerialParallel.so: >> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >> little-endian (Possible cause: endianness mismatch) >> Caught java.lang.UnsatisfiedLinkError: >> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >> >> while loading driver com.sun.comm.SolarisDriver >> >> Is there a way around this error? >> > > What host OS are you running? From your original post it looks like 32 > bit Linux. > > The libSolarisSerialParallel.so file is for Sun Solaris and will vary > depending on the underlying hardware architecture as well. > > I'm running Kubuntu Linux (debian based). It's 32 bit. Rick Knight From jlar310 at gmail.com Wed Aug 6 15:33:23 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 16:33:23 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > I don't think Sun did binary libraries for Linux in the 2.0 version. Can someone with more historical experience than I confirm that? I recently tried to port a Comm API application from Solaris sparc to Linux x86 and likewise could not get my hands on the binary libraries. I eventually just re-wrote the code to use the gnu namespace packages and rxtx 2.1. What I don't understand is why your application vendor does not provide everything you need to run their software. FYI: I have librxtxParallel.so and librxtxSerial.so installed at JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is /usr/java/default which is actually a softlink to /usr/java/jre1.6.0_05. -- Jeff From defiantlew at yahoo.com.au Wed Aug 6 16:29:33 2008 From: defiantlew at yahoo.com.au (Lew L) Date: Thu, 7 Aug 2008 08:29:33 +1000 Subject: [Rxtx] Sun's Comm API Documentation References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> Message-ID: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> As a matter of interest is the Sun Comm API documentation available somewhere? I have tried the Sun site but it seems to have been removed. Unless I have missed the documentation for RXTX? I javadocced the RXTX source but information (to me) is minimal. Somewhere I got the impression that the Sun Comm API docs is, or was, compatible with RXTX, what is the best docs to use in conjuntion with RXTX and where may the be available? Cheers Lew From rick_knight at rlknight.com Wed Aug 6 17:18:33 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:18:33 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A3149.4050306@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff I'm not sure if I posted this here or not, but when I try to build RXTX from source I get this install error... make all-am make[1]: Entering directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' make[1]: Nothing to be done for `all-am'. make[1]: Leaving directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 Can you tell me how to get past this error and get RXTX built and installed? Thanks, Rick From bboyes at systronix.com Wed Aug 6 17:40:12 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Wed, 06 Aug 2008 17:40:12 -0600 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: At 16:29 08/06/2008, Lew L wrote: >As a matter of interest is the Sun Comm API documentation available >somewhere? I have tried the Sun site but it seems to have been removed. It's in the file we have posted, link in prev email (sorry, in a huge hurry right now). Javadocs definitely there. >Unless I have missed the documentation for RXTX? I javadocced the RXTX >source but information (to me) is minimal. >Somewhere I got the impression that the Sun Comm API docs is, or was, >compatible with RXTX, what is the best docs to use in conjuntion with RXTX >and where may the be available? Yeah, this is one of my concerns/beefs. There is little documentation for RXTX and it isn't just the same as javaxcomm. I would be willing to help out writing docs for RXTX! Yes really... esp if we can fix the Bluetooth issues. best regards Bruce >Cheers >Lew > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx ------- WWW.SYSTRONIX.COM ---------- Real embedded Java and much more +1-801-534-1017 Salt Lake City, USA From rick_knight at rlknight.com Wed Aug 6 17:54:08 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:54:08 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A39A0.2090309@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff, I would like for my vendor to switch to rxtx 2.1. It would make things much easier for me. I'm not sure why he's still using the javax compatible code. He's a small operation. Re-writing the code to use gnu namespace sounds like a major overhaul. Was it? Thanks, Rick From tjarvi at qbang.org Wed Aug 6 21:35:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:35:12 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: >> >>> Jeff wrote: >>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>>> >>>> >>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things > much easier for me. I'm not sure why he's still using the javax > compatible code. He's a small operation. Re-writing the code to use gnu > namespace sounds like a major overhaul. Was it? > Hi Jeff, The changes are fairly mechanical. Imports need to change and any explicite use of the namespace needs to change such as catching an exception. The following script was made for maintaining rxtx 2.0 but can apply to other needs. It is in the contrib dir with rxtx source. #!/bin/sh # Don't use! :) # # Sat, 03 May 2003 16:45:08 Modifications from J?rg Weule # Create a ed-cmd for the change of one pattern # case $1 in gnu) X=g/javax_comm/s+javax_comm+gnu_io+g ;; javax) X=g/gnu_io/s+gnu_io+javax_comm+g ;; *) echo;echo;echo From the top rxtx directory run;echo;echo -e \\t./ChangePackage.sh gnu;echo -e \\t\\tor;echo -e \\t./ChangePackage.sh javax;echo;echo; exit 0 ;; esac # # ed will be used to keep the owner and mode of the files unchanged. # We have run the ed-script for the characters '.' '/' as well. # "tr _ $D" do the change. # find . -type f -a -print | grep -v $0 | (while read F ; do ( echo $X; echo $X| tr _ /; echo $X| tr _ .; echo w; echo q ) | ed $F 2>&1 >/dev/null done ) # # Now we do little changes at the Makefiles. Hope that all we need. # find . -name Makefile\* -a -print | (while read F ; do cat < References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: On Thu, 7 Aug 2008, Lew L wrote: > As a matter of interest is the Sun Comm API documentation available > somewhere? I have tried the Sun site but it seems to have been removed. > > Unless I have missed the documentation for RXTX? I javadocced the RXTX > source but information (to me) is minimal. > Somewhere I got the impression that the Sun Comm API docs is, or was, > compatible with RXTX, what is the best docs to use in conjuntion with RXTX > and where may the be available? > Hi Lew, The documentation on Sun's website is accurate. The changes that are problematic in 3.0 are on the backside which rxtx used to plug into. http://java.sun.com/products/javacomm/reference/api/index.html CommPortIdentifier may have some minor differences (judging by the authors notes). -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Aug 6 21:46:08 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:46:08 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > If javax.comm.properties is properly installed and you are using a 2.0 version of Sun's commapi with rxtx 2.0, you should not see the library attempt to load libSolarisSerialParallel.so. Sun CommAPI 3.0 will not work with any version of rxtx as it is hard coded to use the shared library. See the INSTALL file with rxtx-2.0 source for more help with the properties file. -- Trent Jarvi tjarvi at qbang.org From jlar310 at gmail.com Thu Aug 7 06:32:06 2008 From: jlar310 at gmail.com (Jeff) Date: Thu, 7 Aug 2008 07:32:06 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > Jeff wrote: >> >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >> wrote: >> >>> >>> Jeff wrote: >>> >>>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>> wrote: >>>> >>>> >>>> >>>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things much > easier for me. I'm not sure why he's still using the javax compatible code. > He's a small operation. Re-writing the code to use gnu namespace sounds like > a major overhaul. Was it? I found it quite easy. In fact, in order to accommodate the transition, I actually separated all of the code that deals directly with the Comm API or RXTX into a helper class. The helper class was then coded to use reflection to determine which library was available and then instantiate the necessary objects. No direct imports of either library are used. The main application just needs to get it's hands on the IO streams and need not deal directly with the libraries. Other programs may not be so simple... But this doesn't really help you unless your vendor forks over the source code... -- Jeff From rick_knight at rlknight.com Thu Aug 7 09:47:12 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Thu, 07 Aug 2008 08:47:12 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: <489B1900.10108@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >>> wrote: >>> >>> >>>> Jeff wrote: >>>> >>>> >>>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>>> copy of the comm.api and I've copied the library >>>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>>> into the proper places. When I try to run the application, I get this >>>>>> error... >>>>>> >>>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>>> /usr/lib/libSolarisSerialParallel.so: >>>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>>> little-endian (Possible cause: endianness mismatch) >>>>>> Caught java.lang.UnsatisfiedLinkError: >>>>>> >>>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>>> >>>>>> while loading driver com.sun.comm.SolarisDriver >>>>>> >>>>>> Is there a way around this error? >>>>>> >>>>>> >>>>>> >>>>> What host OS are you running? From your original post it looks like 32 >>>>> bit Linux. >>>>> >>>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>>> depending on the underlying hardware architecture as well. >>>>> >>>>> >>>>> >>>>> >>>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>>> >>>> >>>> >>> I don't think Sun did binary libraries for Linux in the 2.0 version. >>> Can someone with more historical experience than I confirm that? >>> >>> I recently tried to port a Comm API application from Solaris sparc to >>> Linux x86 and likewise could not get my hands on the binary libraries. >>> I eventually just re-wrote the code to use the gnu namespace packages >>> and rxtx 2.1. >>> >>> What I don't understand is why your application vendor does not >>> provide everything you need to run their software. >>> >>> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >>> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >>> /usr/java/default which is actually a softlink to >>> /usr/java/jre1.6.0_05. >>> >>> >>> >> Jeff, >> >> I would like for my vendor to switch to rxtx 2.1. It would make things much >> easier for me. I'm not sure why he's still using the javax compatible code. >> He's a small operation. Re-writing the code to use gnu namespace sounds like >> a major overhaul. Was it? >> > > I found it quite easy. In fact, in order to accommodate the > transition, I actually separated all of the code that deals directly > with the Comm API or RXTX into a helper class. The helper class was > then coded to use reflection to determine which library was available > and then instantiate the necessary objects. No direct imports of > either library are used. The main application just needs to get it's > hands on the IO streams and need not deal directly with the libraries. > Other programs may not be so simple... > > But this doesn't really help you unless your vendor forks over the > source code... > > Jeff, This may not help me directly, but I'm going to forward this thread to the vendor. I think he'll be open to making things work. Thanks again, Rick Knight From agusmunioz at gmail.com Thu Aug 7 16:39:51 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Thu, 7 Aug 2008 19:39:51 -0300 Subject: [Rxtx] How to send ack? Message-ID: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Hi, I'm still learning about serial communication and I have some doubts. I've got this question about how to do the following thing in rxtx. I have this hardware that connect to a PC using a serial port. These hardware receives data from a telephone line, proccess it, and then send it forward to the serial port. I've used a program named wincomm that shows what information is send it through the serial port and I have the nex behaviour: The hardware has a buffer where all data is stored, that cannot be sent it through the seria port. The program reads the first data send it by the hardware, and keep reading the same data always. There is a button in the application that says enable Ack, and when I click, then the hardware start to send all the stored information, and all the information is shown. I write a class, using rxtx that reads the serial port, and the same thing happens, it remains reading the same (first) data all the time. And I thing something like the enable Ack I'm missing. How can I do this enable Ack from my java code using rxtx? Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080807/e0a0f9a1/attachment-0034.html From ajmas at sympatico.ca Thu Aug 7 18:26:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 7 Aug 2008 20:26:41 -0400 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: <4BF42297-81E2-4BB8-A89F-1D43588379AE@sympatico.ca> On 6-Aug-08, at 19:40 , Bruce Boyes wrote: >> Unless I have missed the documentation for RXTX? I javadocced the >> RXTX >> source but information (to me) is minimal. >> Somewhere I got the impression that the Sun Comm API docs is, or was, >> compatible with RXTX, what is the best docs to use in conjuntion >> with RXTX >> and where may the be available? > > Yeah, this is one of my concerns/beefs. There is little documentation > for RXTX and it isn't just the same as javaxcomm. > > I would be willing to help out writing docs for RXTX! Yes really... > esp if we can fix the Bluetooth issues. If you want to contribute documentation then the best place to do that is the wiki. If there is anything missing or that could be improved on then please do so. If there are any points that you would like to see improved, for which you don't have the knowledge then ask on the mailing list for a volunteer. Andre From florianmanschwetus at gmx.de Fri Aug 8 03:04:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Fri, 08 Aug 2008 11:04:14 +0200 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Message-ID: <489C0C0E.2020401@gmx.de> Agustin Mu?oz schrieb: > Hi, I'm still learning about serial communication and I have some > doubts. I've got this question about how to do the following thing in rxtx. > I have this hardware that connect to a PC using a serial port. These > hardware receives data from a telephone line, proccess it, and then send > it forward to the serial port. I've used a program named wincomm that > shows what information is send it through the serial port and I have the > nex behaviour: > > The hardware has a buffer where all data is stored, that cannot be sent > it through the seria port. > The program reads the first data send it by the hardware, and keep > reading the same data always. > There is a button in the application that says enable Ack, and when I > click, then the hardware start to send all the stored information, and > all the information is shown. > > I write a class, using rxtx that reads the serial port, and the same > thing happens, it remains reading the same (first) data all the time. > And I thing something like the enable Ack I'm missing. > How can I do this enable Ack from my java code using rxtx? Afaik, a look at man ascii reveals: Okt Dez Hex Char 006 6 06 ACK So, i hope this will do the job: send(6); florian > > Thanks in advance > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/5b4965f8/attachment-0034.bin From agusmunioz at gmail.com Fri Aug 8 16:31:00 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 19:31:00 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <489C0C0E.2020401@gmx.de> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> Message-ID: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Hi Florian, thanks for the answer. By send(6) you mean to get the port OutputStream and write a 6? I try that but it didn't work. Any suggestion? Thanks On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < florianmanschwetus at gmx.de> wrote: > Agustin Mu?oz schrieb: > > Hi, I'm still learning about serial communication and I have some doubts. >> I've got this question about how to do the following thing in rxtx. >> I have this hardware that connect to a PC using a serial port. These >> hardware receives data from a telephone line, proccess it, and then send it >> forward to the serial port. I've used a program named wincomm that shows >> what information is send it through the serial port and I have the nex >> behaviour: >> >> The hardware has a buffer where all data is stored, that cannot be sent >> it through the seria port. >> The program reads the first data send it by the hardware, and keep reading >> the same data always. >> There is a button in the application that says enable Ack, and when I >> click, then the hardware start to send all the stored information, and all >> the information is shown. >> >> I write a class, using rxtx that reads the serial port, and the same thing >> happens, it remains reading the same (first) data all the time. And I thing >> something like the enable Ack I'm missing. >> How can I do this enable Ack from my java code using rxtx? >> > Afaik, a look at man ascii reveals: > Okt Dez Hex Char > 006 6 06 ACK > So, i hope this will do the job: > send(6); > > florian > >> >> Thanks in advance >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/7f3fba42/attachment-0033.html From agusmunioz at gmail.com Fri Aug 8 18:39:27 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 21:39:27 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Message-ID: <988288430808081739x7f9e7889id82591d5a9e2b4f6@mail.gmail.com> Ok, Florian, it works!! my problem was that I've been sending, through the OutputStream, the bytes of 6 as a string: out.write("6".getBytes()); but then I realized that you can write an int on an OuptuStream, so I tried that and It works: out.write(6); Thank you for the guidance!! On Fri, Aug 8, 2008 at 7:31 PM, Agustin Mu?oz wrote: > Hi Florian, thanks for the answer. By send(6) you mean to get the port > OutputStream and write a 6? > > I try that but it didn't work. > > Any suggestion? > > Thanks > > > On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < > florianmanschwetus at gmx.de> wrote: > >> Agustin Mu?oz schrieb: >> >> Hi, I'm still learning about serial communication and I have some doubts. >>> I've got this question about how to do the following thing in rxtx. >>> I have this hardware that connect to a PC using a serial port. These >>> hardware receives data from a telephone line, proccess it, and then send it >>> forward to the serial port. I've used a program named wincomm that shows >>> what information is send it through the serial port and I have the nex >>> behaviour: >>> >>> The hardware has a buffer where all data is stored, that cannot be sent >>> it through the seria port. >>> The program reads the first data send it by the hardware, and keep >>> reading the same data always. >>> There is a button in the application that says enable Ack, and when I >>> click, then the hardware start to send all the stored information, and all >>> the information is shown. >>> >>> I write a class, using rxtx that reads the serial port, and the same >>> thing happens, it remains reading the same (first) data all the time. And I >>> thing something like the enable Ack I'm missing. >>> How can I do this enable Ack from my java code using rxtx? >>> >> Afaik, a look at man ascii reveals: >> Okt Dez Hex Char >> 006 6 06 ACK >> So, i hope this will do the job: >> send(6); >> >> florian >> >>> >>> Thanks in advance >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/b918ab3d/attachment-0033.html From florianmanschwetus at gmx.de Sat Aug 9 00:45:43 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Sat, 09 Aug 2008 08:45:43 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4899667C.6010706@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> Message-ID: <489D3D17.9090209@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >> Florian Manschwetus wrote: >>> Ok, sounds fine for the receiving problem. >>> But why i have to wait after each byte when sending a command squence? >>> (the for loop in send command) >> >> Hi Florian, >> I'd imagine you probably don't! You could send all bytes in one go and >> RXTX would send them. The problem is most probably the other end: >> perhaps it has a really small buffer, some non-standard UART, or a >> crazy timing issue. If you attach a terminal to your output and send >> all the bytes of a command in one go they should appear no problem. >> >> Regards, >> Michael Erskine. >> > correct with a terminal on the other end it works, my idea was that this > basic baud has some influence. Could some one explain what it is for? > > Florian To make it more clear, my problem is that i can't use: outputStream.write(byte[]); => Beamer doesn't understand the sequence. (mostly no answer when he answers then *001) when i use this construct instead: for (int i = 0; i < command.length; i++) { this.outputStream.write(command[i]); try { Thread.sleep(25); } catch (InterruptedException e) { // TODO Auto-generated catch block e.printStackTrace(); } } it works nearly reliable. So what could it be? This Basic Baud is what exactly? Florian -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080809/692304ee/attachment-0033.bin From tjarvi at qbang.org Sat Aug 9 16:37:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Aug 2008 16:37:19 -0600 (MDT) Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489D3D17.9090209@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> <489D3D17.9090209@gmx.de> Message-ID: On Sat, 9 Aug 2008, Florian Manschwetus wrote: > Florian Manschwetus schrieb: >> Michael Erskine schrieb: >>> Florian Manschwetus wrote: >>>> Ok, sounds fine for the receiving problem. >>>> But why i have to wait after each byte when sending a command squence? >>>> (the for loop in send command) >>> >>> Hi Florian, >>> I'd imagine you probably don't! You could send all bytes in one go and >>> RXTX would send them. The problem is most probably the other end: perhaps >>> it has a really small buffer, some non-standard UART, or a crazy timing >>> issue. If you attach a terminal to your output and send all the bytes of a >>> command in one go they should appear no problem. >>> >>> Regards, >>> Michael Erskine. >>> >> correct with a terminal on the other end it works, my idea was that this >> basic baud has some influence. Could some one explain what it is for? >> >> Florian > To make it more clear, > my problem is that i can't use: > outputStream.write(byte[]); > => Beamer doesn't understand the sequence. (mostly no answer when he answers > then *001) > > when i use this construct instead: > > for (int i = 0; i < command.length; i++) { > this.outputStream.write(command[i]); > try { > Thread.sleep(25); > } catch (InterruptedException e) { > // TODO Auto-generated catch block > e.printStackTrace(); > } > } > > it works nearly reliable. > > So what could it be? This Basic Baud is what exactly? > I suspect you are using the 'moon protocol' and don't know it. RXTX enables this by default. The buffer on the other end is first in first out while reading. If the buffer is full, the bits are hand carried to the moon and burried. Then if the other side reads a couple bytes, two more bytes go into the buffer followed by more moon protocol. The resulting array of bytes the other side reads may appear to be scrambled until you go to the moon, get the bits and insert them in the right place. Flow control can prevent the default moon protocol and throttles the communiation by almost writing a byte at a time as need be. Hardware flow control is preferable but software flow control should also work. Read and write can appear to hang if the other side is not connected. This is why we don't enable them all the time. If you can't use flow control, you have to take care with the moon protocol and give the other side time to read. That is what your slower version of write is doing. -- Trent Jarvi tjarvi at qbang.org From rxtx at allenjb.me.uk Mon Aug 11 08:06:36 2008 From: rxtx at allenjb.me.uk (AllenJB) Date: Mon, 11 Aug 2008 15:06:36 +0100 Subject: [Rxtx] Disabling EV_RXFLAG Message-ID: <48A0476C.2090800@allenjb.me.uk> Hi all, I'm working with a device which does not use an EvtChar and need to disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an event mask of FD 01 00 00. The reference software I have uses FB 00 00 00. With the rxtx mask I get framing errors which I believe are caused when the EvtChar is received. Is there currently a way with rxtx (I've using rxtx from Java) to disable EV_RXFLAG? If not from Java, where would I start if I wanted to turn the EV_RXFLAG option off in the C code? I've had a grep of the rxtx source code, but I can't see where EV_RXFLAG is being set. Thanks in advance, AllenJB From tjarvi at qbang.org Mon Aug 11 14:17:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Aug 2008 14:17:27 -0600 (MDT) Subject: [Rxtx] Disabling EV_RXFLAG In-Reply-To: <48A0476C.2090800@allenjb.me.uk> References: <48A0476C.2090800@allenjb.me.uk> Message-ID: On Mon, 11 Aug 2008, AllenJB wrote: > Hi all, > > I'm working with a device which does not use an EvtChar and need to > disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an > event mask of FD 01 00 00. The reference software I have uses FB 00 00 > 00. With the rxtx mask I get framing errors which I believe are caused > when the EvtChar is received. > > Is there currently a way with rxtx (I've using rxtx from Java) to > disable EV_RXFLAG? > > If not from Java, where would I start if I wanted to turn the EV_RXFLAG > option off in the C code? I've had a grep of the rxtx source code, but I > can't see where EV_RXFLAG is being set. > > Thanks in advance, > > AllenJB Hi Allen, I'd look at termios.c::tcsetattr() and termios.c::FillDCB() -- Trent Jarvi tjarvi at qbang.org From superdadusa at gmail.com Tue Aug 12 13:57:32 2008 From: superdadusa at gmail.com (John Choi) Date: Tue, 12 Aug 2008 13:57:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. Message-ID: Hi all, Just let you all know I just start to learn Java. I have download the serial comm package and the source code from open source communities.. I was able to verify with the given message string via serial monitor. when the given message string sends to the serial port then the character return added to the end of string by default if I use "Hello World" however if I changed to something else other than "Hello, World" there is no character return add to the end of string. I thing the library download from rxtx.org has implemented for the special strings. I can do like "login\n" in the string message to make character return but I don't want to add this individual custom character for each command return in every static message string I send, Can any who have done this might help me? Basically, something like this,, Write and add function to the program write a command, Reads the respond from a serial device.. Function handles multiple messages, Write: "com open" Read: Welcome to my world" expected Write: "admin" Read: Password?, expected Write: "admin" Read: you are successfully login terminal, expected. And I need to add a separate function handler handles a character return add to the each command above. If anyone can help this I can do the reset? Thank you in advance, John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0029.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SerialIO.java Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0029.pl From Steffen.DETTMER at ingenico.com Wed Aug 13 02:16:38 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 13 Aug 2008 10:16:38 +0200 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: References: Message-ID: <20080813081638.GA25412@elberon.bln.de.ingenico.com> * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > I can do like "login\n" in the string message to make character > return but I don't want to add this individual custom character > for each command return in every static message string I send, and why not?! > Can any who have done this might help me? what's about with writing a small wrapper function adding the carriage return? However, this would be slow, because either you call write two times (very bad) or the string needs to be copied, \n appended and written (since you are using Java Performance probably isn't so critical). Personally I would write `"login\n"' and `username + "\n"' etc., because since it is part of the command it should be part of the command definition string. > Basically, something like this,, Write and add function to the program write > a command, Reads the respond from a serial device.. correctly reading a `line' is more difficult. If you cannot make assumptions about timeouts and/or you need to have low delay, you need to read byte wise. If you need to save CPU resources you might need to add some buffering layer that you can read byte-wise but that is reading blockwise with some small timeout (lets say for serial lines something around byte transmission time times three or so). > /* > * To change this template, choose Tools | Templates > * and open the template in the editor. > */ :) > package joliba; > > /** > * > * @author root > */ :) > // derived from SUN's examples in the javax.comm package > import java.io.*; > import java.util.*; > //import javax.comm.*; // for SUN's serial/parallel port libraries > import gnu.io.*; // for rxtxSerial library > > public class SerialIO implements Runnable, SerialPortEventListener { > static CommPortIdentifier portId; > static CommPortIdentifier saveportId; > static Enumeration portList; > InputStream inputStream; > SerialPort serialPort; > Thread readThread; You need a thread for your synchronous RPC-style protocol? > static String messageString = "Hello, world!"; > static OutputStream outputStream; > static boolean outputBufferEmptyFlag = false; > > public static void main(String[] args) { > boolean portFound = false; > String defaultPort; > > // determine the name of the serial port on several operating systems > String osname = System.getProperty("os.name","").toLowerCase(); > if ( osname.startsWith("windows") ) { > // windows > defaultPort = "COM1"; > } else if (osname.startsWith("linux")) { > // linux > defaultPort = "/dev/ttyS0"; > } else if ( osname.startsWith("mac") ) { > // mac > defaultPort = "????"; > } else { > System.out.println("Sorry, your operating system is not supported"); > return; > } Is such a construction recommended? Isn't there some abstraction (like COM1 working on any platform)? [...] > try { > // activate the OUTPUT_BUFFER_EMPTY notifier > serialPort.notifyOnOutputEmpty(true); > } catch (Exception e) { > System.out.println("Error setting event notification"); > System.out.println(e.toString()); > System.exit(-1); > } I doubt that -1 is defined, probably some 127 or so would be the result, maybe better simply `throw e'? > public void writetoport() { > System.out.println("Writing \""+messageString+"\" to "+serialPort.getName()); > try { > // write string to serial port > outputStream.write(messageString.getBytes()); > } catch (IOException e) {} > } maybe something like /** * Writes the given output string and an additional carriage * return to the current outputStream. */ public void writeStringToPort( /** The output string (without CR). */ String output ) throws IOException { String outputLine = output + "\n"; outputStream.write(outputLine.getBytes()); } ? > > public SerialIO() { > // initalize serial port > try { > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > } catch (PortInUseException e) {} if the port is in use, you continue? Wonder that this works in Java, I would assume serialPort beeing uninitialized which AFAIK is an error in Java. > try { > inputStream = serialPort.getInputStream(); > } catch (IOException e) {} > > try { > serialPort.addEventListener(this); > } catch (TooManyListenersException e) {} > > // activate the DATA_AVAILABLE notifier > serialPort.notifyOnDataAvailable(true); > > try { > // set port parameters > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > } catch (UnsupportedCommOperationException e) {} > > // start the read thread > readThread = new Thread(this); > readThread.start(); > > } I think in all those exception cases you can abort, because it is unlikely that ignoring those errors allow a successful continuation, so in this case maybe it would be better to add a throw clause to the method. > public void run() { > // first thing in the thread, we initialize the write operation > initwritetoport(); > try { > while (true) { > // write string to port, the serialEvent will read it > writetoport(); > Thread.sleep(1000); > } > } catch (InterruptedException e) {} > } Does this make sense? Your `SimpleReadApp' writes one and the same string each second? > public void serialEvent(SerialPortEvent event) { > switch (event.getEventType()) { > case SerialPortEvent.BI: > case SerialPortEvent.OE: > case SerialPortEvent.FE: > case SerialPortEvent.PE: > case SerialPortEvent.CD: > case SerialPortEvent.CTS: > case SerialPortEvent.DSR: > case SerialPortEvent.RI: > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > break; > case SerialPortEvent.DATA_AVAILABLE: > // we get here if data has been received > byte[] readBuffer = new byte[20]; > try { > // read data > while (inputStream.available() > 0) { > int numBytes = inputStream.read(readBuffer); > } > // print data > String result = new String(readBuffer); > System.out.println("Read: "+result); > } catch (IOException e) {} I doubt that this is correct. I would assume you will get a 20 bytes result always, if more bytes would be available they would be printed in a second line but if less bytes are read I'd assume that the buffer/result contains zero bytes from implicite readBuffer contents initialisation (zero is no string terminator in Java AFAIK). > break; > } > } > } oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From florianmanschwetus at gmx.de Wed Aug 13 06:09:31 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 13 Aug 2008 14:09:31 +0200 Subject: [Rxtx] someone has seen such errors? Message-ID: <48A2CEFB.90007@gmx.de> I mean my communication mostly works, but it is far from perfect could this be the reason? Florian Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/949b9947/attachment-0029.bin From superdadusa at gmail.com Wed Aug 13 08:40:32 2008 From: superdadusa at gmail.com (John Choi) Date: Wed, 13 Aug 2008 08:40:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: <20080813081638.GA25412@elberon.bln.de.ingenico.com> References: <20080813081638.GA25412@elberon.bln.de.ingenico.com> Message-ID: Thank you so much Steffen and I will try that suggestion. John On 8/13/08, Steffen DETTMER wrote: > > * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > > I can do like "login\n" in the string message to make character > > return but I don't want to add this individual custom character > > for each command return in every static message string I send, > > and why not?! > > > Can any who have done this might help me? > > what's about with writing a small wrapper function adding the > carriage return? > However, this would be slow, because either you call write two > times (very bad) or the string needs to be copied, \n appended > and written (since you are using Java Performance probably isn't > so critical). > > Personally I would write `"login\n"' and `username + "\n"' etc., > because since it is part of the command it should be part of the > command definition string. > > > Basically, something like this,, Write and add function to the program > write > > a command, Reads the respond from a serial device.. > > correctly reading a `line' is more difficult. If you cannot make > assumptions about timeouts and/or you need to have low delay, you > need to read byte wise. If you need to save CPU resources you > might need to add some buffering layer that you can read > byte-wise but that is reading blockwise with some small timeout > (lets say for serial lines something around byte transmission > time times three or so). > > > /* > > * To change this template, choose Tools | Templates > > * and open the template in the editor. > > */ > > :) > > > package joliba; > > > > /** > > * > > * @author root > > */ > > :) > > > // derived from SUN's examples in the javax.comm package > > import java.io.*; > > import java.util.*; > > //import javax.comm.*; // for SUN's serial/parallel port libraries > > import gnu.io.*; // for rxtxSerial library > > > > public class SerialIO implements Runnable, SerialPortEventListener { > > static CommPortIdentifier portId; > > static CommPortIdentifier saveportId; > > static Enumeration portList; > > InputStream inputStream; > > SerialPort serialPort; > > Thread readThread; > > You need a thread for your synchronous RPC-style protocol? > > > static String messageString = "Hello, world!"; > > static OutputStream outputStream; > > static boolean outputBufferEmptyFlag = false; > > > > public static void main(String[] args) { > > boolean portFound = false; > > String defaultPort; > > > > // determine the name of the serial port on several operating > systems > > String osname = System.getProperty("os.name","").toLowerCase(); > > if ( osname.startsWith("windows") ) { > > // windows > > defaultPort = "COM1"; > > } else if (osname.startsWith("linux")) { > > // linux > > defaultPort = "/dev/ttyS0"; > > } else if ( osname.startsWith("mac") ) { > > // mac > > defaultPort = "????"; > > } else { > > System.out.println("Sorry, your operating system is not > supported"); > > return; > > } > > Is such a construction recommended? Isn't there some abstraction > (like COM1 working on any platform)? > > [...] > > try { > > // activate the OUTPUT_BUFFER_EMPTY notifier > > serialPort.notifyOnOutputEmpty(true); > > } catch (Exception e) { > > System.out.println("Error setting event notification"); > > System.out.println(e.toString()); > > System.exit(-1); > > } > > I doubt that -1 is defined, probably some 127 or so would be the > result, maybe better simply `throw e'? > > > public void writetoport() { > > System.out.println("Writing \""+messageString+"\" to > "+serialPort.getName()); > > try { > > // write string to serial port > > outputStream.write(messageString.getBytes()); > > } catch (IOException e) {} > > } > > maybe something like > > /** > * Writes the given output string and an additional carriage > * return to the current outputStream. > */ > public void > writeStringToPort( > /** The output string (without CR). */ > String output > ) throws IOException > { > String outputLine = output + "\n"; > outputStream.write(outputLine.getBytes()); > } > > ? > > > > > public SerialIO() { > > // initalize serial port > > try { > > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > > } catch (PortInUseException e) {} > > if the port is in use, you continue? Wonder that this works in > Java, I would assume serialPort beeing uninitialized which AFAIK > is an error in Java. > > > try { > > inputStream = serialPort.getInputStream(); > > } catch (IOException e) {} > > > > try { > > serialPort.addEventListener(this); > > } catch (TooManyListenersException e) {} > > > > // activate the DATA_AVAILABLE notifier > > serialPort.notifyOnDataAvailable(true); > > > > try { > > // set port parameters > > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > } catch (UnsupportedCommOperationException e) {} > > > > // start the read thread > > readThread = new Thread(this); > > readThread.start(); > > > > } > > I think in all those exception cases you can abort, because it is > unlikely that ignoring those errors allow a successful > continuation, so in this case maybe it would be better to add a > throw clause to the method. > > > public void run() { > > // first thing in the thread, we initialize the write operation > > initwritetoport(); > > try { > > while (true) { > > // write string to port, the serialEvent will read it > > writetoport(); > > Thread.sleep(1000); > > } > > } catch (InterruptedException e) {} > > } > > Does this make sense? Your `SimpleReadApp' writes one and the > same string each second? > > > public void serialEvent(SerialPortEvent event) { > > switch (event.getEventType()) { > > case SerialPortEvent.BI: > > case SerialPortEvent.OE: > > case SerialPortEvent.FE: > > case SerialPortEvent.PE: > > case SerialPortEvent.CD: > > case SerialPortEvent.CTS: > > case SerialPortEvent.DSR: > > case SerialPortEvent.RI: > > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > > break; > > case SerialPortEvent.DATA_AVAILABLE: > > // we get here if data has been received > > byte[] readBuffer = new byte[20]; > > try { > > // read data > > while (inputStream.available() > 0) { > > int numBytes = inputStream.read(readBuffer); > > } > > // print data > > String result = new String(readBuffer); > > System.out.println("Read: "+result); > > } catch (IOException e) {} > > I doubt that this is correct. I would assume you will get a 20 > bytes result always, if more bytes would be available they would > be printed in a second line but if less bytes are read I'd assume > that the buffer/result contains zero bytes from implicite > readBuffer contents initialisation (zero is no string terminator > in Java AFAIK). > > > break; > > } > > } > > } > > oki, > > Steffen > > About Ingenico Throughout the world businesses rely on Ingenico for secure > and expedient electronic transaction acceptance. Ingenico products leverage > proven technology, established standards and unparalleled ergonomics to > provide optimal reliability, versatility and usability. This comprehensive > range of products is complemented by a global array of services and > partnerships, enabling businesses in a number of vertical sectors to accept > transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged > information. If you are not the addressee or authorized to receive this for > the addressee, you must not use, copy, disclose or take any action based on > this message or any information herein. If you have received this message in > error, please advise the sender immediately by reply e-mail and delete this > message. Thank you for your cooperation. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/73c4135c/attachment-0028.html From ajmas at sympatico.ca Sat Aug 16 07:15:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 09:15:41 -0400 Subject: [Rxtx] someone has seen such errors? In-Reply-To: <48A2CEFB.90007@gmx.de> References: <48A2CEFB.90007@gmx.de> Message-ID: <43B5E8DA-1D93-4D90-809B-AAF35FF724C5@sympatico.ca> On 13-Aug-08, at 08:09 , Florian Manschwetus wrote: > I mean my communication mostly works, but it is far from perfect > could this be the reason? > > Florian > > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control Judging by the error messages this looks related to the driver you are using. Do a search for the following string with you favourite search engine, it should turn up a few hits: ftdi_set_termios FAILED to set databits/stopbits/parity Andre From ajmas at sympatico.ca Sat Aug 16 19:12:04 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 21:12:04 -0400 Subject: [Rxtx] Using SerialPortEvent? Message-ID: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Hi, Could someone tell me how I should be using the SerialPortEvent? Am I meant to be waiting for data and then simply reading from the inputstream? If this is the case why no just block on an inputstream read? Andr? From tjarvi at qbang.org Sat Aug 16 19:41:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 16 Aug 2008 19:41:13 -0600 (MDT) Subject: [Rxtx] Using SerialPortEvent? In-Reply-To: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> References: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Message-ID: On Sat, 16 Aug 2008, Andre-John Mas wrote: > Hi, > > Could someone tell me how I should be using the SerialPortEvent? Am I > meant to be waiting for data and then simply reading from the > inputstream? If this is the case why no just block on an inputstream > read? > Polling for data is fine also. It really depends upon what you are trying to do. For instance, if you require x bytes before reading, you can start polling after data is available. If you read on the same thread as your GUI and are waiting for data in a read, the results may be less than desirable. Java programming is 'usually' event driven rather than polling based. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sat Aug 16 20:10:39 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 22:10:39 -0400 Subject: [Rxtx] Using SerialPortEvent? In-Reply-To: References: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Message-ID: <3E495D4C-BB28-4845-A6AB-984C9A826BDF@sympatico.ca> On 16-Aug-08, at 21:41 , Trent Jarvi wrote: > On Sat, 16 Aug 2008, Andre-John Mas wrote: > >> Hi, >> >> Could someone tell me how I should be using the SerialPortEvent? Am I >> meant to be waiting for data and then simply reading from the >> inputstream? If this is the case why no just block on an inputstream >> read? >> > > Polling for data is fine also. It really depends upon what you are > trying to do. For instance, if you require x bytes before reading, > you can start polling after data is available. If you read on the > same thread as your GUI and are waiting for data in a read, the > results may be less than desirable. > > Java programming is 'usually' event driven rather than polling based. Sounds good. I thought I would use this opportunity to provide a event based version of the TwoWaySerialComm example. Could you just validate it before I add it to the Wiki: package ajmas74.experimental; import gnu.io.CommPort; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; import gnu.io.SerialPortEvent; import gnu.io.SerialPortEventListener; import java.io.IOException; import java.io.InputStream; import java.io.OutputStream; /** * This version of the TwoWaySerialComm example makes use of the * SerialPortEventListener to avoid polling. * * @author ajmas * */ public class TwoWaySerialComm { public TwoWaySerialComm() { super(); } void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { CommPort commPort = portIdentifier.open(this.getClass().getName(),2000); if ( commPort instanceof SerialPort ) { SerialPort serialPort = (SerialPort) commPort; serialPort .setSerialPortParams (57600 ,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); (new Thread(new SerialWriter(out))).start(); serialPort.addEventListener(new SerialReader(in)); } else { System.out.println("Error: Only serial ports are handled by this example."); } } } /** * Handles the input coming from the serial port. A new line character * is treated as the end of a block in this example. */ public static class SerialReader implements SerialPortEventListener { private InputStream in; private byte[] buffer = new byte[1024]; public SerialReader ( InputStream in ) { this.in = in; } public void serialEvent(SerialPortEvent arg0) { int data; try { int len = 0; while ( ( data = in.read()) > -1 ) { if ( data != '\n' ) { break; } buffer[len++] = (byte) data; } System.out.print(new String(buffer,0,len)); } catch ( IOException e ) { e.printStackTrace(); System.exit(-1); } } } /** */ public static class SerialWriter implements Runnable { OutputStream out; public SerialWriter ( OutputStream out ) { this.out = out; } public void run () { try { int c = 0; while ( ( c = System.in.read()) > -1 ) { this.out.write(c); } } catch ( IOException e ) { e.printStackTrace(); System.exit(-1); } } } public static void main ( String[] args ) { try { (new TwoWaySerialComm()).connect("COM3"); } catch ( Exception e ) { e.printStackTrace(); } } } From lfarkas at lfarkas.org Tue Aug 19 07:32:59 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Tue, 19 Aug 2008 15:32:59 +0200 Subject: [Rxtx] JNI or CNI Message-ID: <48AACB8B.9060606@lfarkas.org> hi, what is the current recommended way to rxtx on linux JNI or it's better to use CNI? is the CNI version fully functional and the same level as the JNI? i currently try to make a rhel/centos/fedora rpm for rxtx but has many problems with the standard dir structure. yours. -- Levente "Si vis pacem para bellum!" From lfarkas at lfarkas.org Tue Aug 19 08:47:34 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Tue, 19 Aug 2008 16:47:34 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel Message-ID: <48AADD06.7040809@lfarkas.org> hi, newer or not so newer linux kernel do not contain the UTS_RELEASE so the current rxtx is not compile on the latest kernels. even if it's commented out in the cvs configure there are other places. i attcahed a patch which fix it (or at least doesn't cause error at non-debug build). ps. is there any plan to the new 2.1-8 release in the near future? there are many changes (at least the license change in all file and in this case create a diff is very difficult)? the latest release more then 2 years old:-( -- Levente "Si vis pacem para bellum!" -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-2.1-uts.patch Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080819/ab5d38ac/attachment-0022.pl From ajmas at sympatico.ca Tue Aug 19 16:21:53 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 19 Aug 2008 18:21:53 -0400 Subject: [Rxtx] Event based example Message-ID: <24735BFB-B088-4B84-8173-FE98DF63B12F@sympatico.ca> Hi, I have just posted an example of using SerialPortEventListener in the Wiki: http://rxtx.qbang.org/wiki/index.php/Event_Based_Two_Way_Communication If you see any issues please could you let me know, or makes the changes. Andre From Martin.Oberhuber at windriver.com Fri Aug 22 04:02:24 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 22 Aug 2008 12:02:24 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <48AADD06.7040809@lfarkas.org> References: <48AADD06.7040809@lfarkas.org> Message-ID: <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> Farkas, there are indeed efforts to get a new RXTX release out the door. Your experience as a package maintainer would likely be helpful during these efforts, since I'd think it makes sense to keep the patches minimal that you must make to have the source compile in your environment. What are the things that you find problematic, apart from the UTS thing that you have mentioned before? What is the timing that you have in mind for your package? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Farkas Levente > Sent: Tuesday, August 19, 2008 4:48 PM > To: rxtx at qbang.org > Subject: [Rxtx] UTS_RELEASE not defined in newer kernel > > hi, > newer or not so newer linux kernel do not contain the > UTS_RELEASE so the > current rxtx is not compile on the latest kernels. even if it's > commented out in the cvs configure there are other places. > i attcahed a patch which fix it (or at least doesn't cause error at > non-debug build). > > ps. is there any plan to the new 2.1-8 release in the near > future? there > are many changes (at least the license change in all file and in this > case create a diff is very difficult)? the latest release more then 2 > years old:-( > > -- > Levente "Si vis pacem para bellum!" > From lfarkas at lfarkas.org Fri Aug 22 04:36:26 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Fri, 22 Aug 2008 12:36:26 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> References: <48AADD06.7040809@lfarkas.org> <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> Message-ID: <48AE96AA.6090505@lfarkas.org> hi, the packages already build for fedora-9 and centos-5 and here: http://www.lfarkas.org/linux/packages/ what i've to patch, the UTS, the configure script, but it's already fixed in the cvs (in another way) and the loadlibrary. the reasons for last one can be found here: https://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_files_that_use_JNI after we test it i'd like to add these packages to fedora and epel main repository (that's why it's be useful a new release after 2 years:-) imho versions are cheap and why not just release 2.1-8? the real code changes are minimal and if something critical bug found still can release 2.1-9:-) ps. and would be better to use simple number for version like 2.1-7 rather then 2.1-7v2. Oberhuber, Martin wrote: > Farkas, > > there are indeed efforts to get a new RXTX release out the > door. Your experience as a package maintainer would likely > be helpful during these efforts, since I'd think it makes > sense to keep the patches minimal that you must make to > have the source compile in your environment. > > What are the things that you find problematic, apart from > the UTS thing that you have mentioned before? > > What is the timing that you have in mind for your package? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >> On Behalf Of Farkas Levente >> Sent: Tuesday, August 19, 2008 4:48 PM >> To: rxtx at qbang.org >> Subject: [Rxtx] UTS_RELEASE not defined in newer kernel >> >> hi, >> newer or not so newer linux kernel do not contain the >> UTS_RELEASE so the >> current rxtx is not compile on the latest kernels. even if it's >> commented out in the cvs configure there are other places. >> i attcahed a patch which fix it (or at least doesn't cause error at >> non-debug build). >> >> ps. is there any plan to the new 2.1-8 release in the near >> future? there >> are many changes (at least the license change in all file and in this >> case create a diff is very difficult)? the latest release more then 2 >> years old:-( >> >> -- >> Levente "Si vis pacem para bellum!" >> -- Levente "Si vis pacem para bellum!" From tjarvi at qbang.org Fri Aug 22 18:50:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Aug 2008 18:50:32 -0600 (MDT) Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <48AE96AA.6090505@lfarkas.org> References: <48AADD06.7040809@lfarkas.org> <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> <48AE96AA.6090505@lfarkas.org> Message-ID: Hi Farkas, The v2 was simply the second build - no code changes. We are comming out with a new release shortly. I would encourage working with distros as you are. The building of rxtx turns out to be a bottle neck in quick releases. We do want stable releases that work for a year or more but I would have no problems with quicker cycles on developing work. I would have no problem working with someone that did builds that receive less testing more often but they do have to come out for multiple platforms from this end. Thanks for the links. On Fri, 22 Aug 2008, Farkas Levente wrote: > hi, > the packages already build for fedora-9 and centos-5 and here: > http://www.lfarkas.org/linux/packages/ > what i've to patch, the UTS, the configure script, but it's already > fixed in the cvs (in another way) and the loadlibrary. the reasons for > last one can be found here: > https://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_files_that_use_JNI > after we test it i'd like to add these packages to fedora and epel main > repository (that's why it's be useful a new release after 2 years:-) > imho versions are cheap and why not just release 2.1-8? the real code > changes are minimal and if something critical bug found still can > release 2.1-9:-) > > ps. and would be better to use simple number for version like 2.1-7 > rather then 2.1-7v2. > > Oberhuber, Martin wrote: >> Farkas, >> >> there are indeed efforts to get a new RXTX release out the >> door. Your experience as a package maintainer would likely >> be helpful during these efforts, since I'd think it makes >> sense to keep the patches minimal that you must make to >> have the source compile in your environment. >> >> What are the things that you find problematic, apart from >> the UTS thing that you have mentioned before? >> >> What is the timing that you have in mind for your package? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >>> On Behalf Of Farkas Levente >>> Sent: Tuesday, August 19, 2008 4:48 PM >>> To: rxtx at qbang.org >>> Subject: [Rxtx] UTS_RELEASE not defined in newer kernel >>> >>> hi, >>> newer or not so newer linux kernel do not contain the >>> UTS_RELEASE so the >>> current rxtx is not compile on the latest kernels. even if it's >>> commented out in the cvs configure there are other places. >>> i attcahed a patch which fix it (or at least doesn't cause error at >>> non-debug build). >>> >>> ps. is there any plan to the new 2.1-8 release in the near >>> future? there >>> are many changes (at least the license change in all file and in this >>> case create a diff is very difficult)? the latest release more then 2 >>> years old:-( >>> >>> -- >>> Levente "Si vis pacem para bellum!" >>> > > > From andy at triera.net Sat Aug 23 15:17:44 2008 From: andy at triera.net (Andy Rozman) Date: Sat, 23 Aug 2008 21:17:44 +0000 Subject: [Rxtx] port not identified on FreeBSD In-Reply-To: References: Message-ID: <48B07E78.2030306@triera.net> Hi ! I have one small problem... I have started using FreeBSD in last few days and I have come accross a problem with rxtx on FreeBSD. I am using usb-to-serial converter, which is identified under FreeBSD without problem as ucom0, and creates link under /dev called ttyU0, which is correct way to be done under FreeBSD (if device would be unidentified it would be called ugen0 - as usb generic). Problem is that I say to rxtx to get my all serial ports this one is not among them. Which names are permissable under linux-like implementations? Which will be accepted as serial ports? Andy From tjarvi at qbang.org Sat Aug 23 13:57:45 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 23 Aug 2008 13:57:45 -0600 (MDT) Subject: [Rxtx] port not identified on FreeBSD In-Reply-To: <48B07E78.2030306@triera.net> References: <48B07E78.2030306@triera.net> Message-ID: On Sat, 23 Aug 2008, Andy Rozman wrote: > Hi ! > > I have one small problem... I have started using FreeBSD in last few > days and I have come accross a problem with rxtx on FreeBSD. > > I am using usb-to-serial converter, which is identified under FreeBSD > without problem as ucom0, and creates link under /dev called > ttyU0, which is correct way to be done under FreeBSD (if device would be > unidentified it would be called ugen0 - as usb generic). Problem is that > I say to rxtx to get my all serial ports this one is not among them. > Which names are permissable under linux-like implementations? Which will > be accepted as serial ports? > > Andy > Thanks Andy! We will add ttyU* to FreeBSD. For now you can use properties to enable the port. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting#How_does_rxtx_detect_ports.3F__Can_I_override_it.3F The fix: diff -u -r1.16.2.59 RXTXCommDriver.java --- RXTXCommDriver.java 18 Nov 2007 22:32:41 -0000 1.16.2.59 +++ RXTXCommDriver.java 23 Aug 2008 19:55:25 -0000 @@ -644,6 +644,7 @@ { String[] Temp = { "ttyd", //general purpose serial ports + "ttyU", //general purpose USB serial ports "cuaa", //dialout serial ports "ttyA", //Specialix SI/XIO dialin ports "cuaA", //Specialix SI/XIO dialout ports -- Trent Jarvi tjarvi at qbang.org From rick_knight at rlknight.com Mon Aug 4 13:25:10 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Mon, 04 Aug 2008 12:25:10 -0700 Subject: [Rxtx] Sun's Comm API? Message-ID: <48975796.4010600@rlknight.com> I have an application that requires the javax compatible version of RXTX and Sun's comm api. I've been able to download and extract the version of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api anywhere. Can someone tell me where I can find it? Or maybe send me a copy? Also, when I try to build RXTX, configure and make complete successfully but make install failes with this error libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 I've never come accross this error before. How can I get past it? Thanks, Rick From bboyes at systronix.com Mon Aug 4 19:10:01 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:10:01 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48975796.4010600@rlknight.com> References: <48975796.4010600@rlknight.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/cb9c6167/attachment-0038.html From bboyes at systronix.com Mon Aug 4 19:12:37 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:12:37 -0600 Subject: [Rxtx] Towards an RXTX release - CSR BT/USB chipset In-Reply-To: <488FB7E7.8000802@gmail.com> References: <460801A4097E3D4CA04CC64EE648584806C56CF0@ism-mail03.corp.ad.wrs.com> <13557-75390@sneakemail.com> <20980-23424@sneakemail.com> <488FB7E7.8000802@gmail.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/52236088/attachment-0038.html From tjarvi at qbang.org Mon Aug 4 19:42:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 19:42:21 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: On Mon, 4 Aug 2008, Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: > I have an application that requires the javax compatible > version of RXTX > and Sun's comm api. I've been able to download and extract > the version > of RXTX that I need (2.0-7pre2) but I can't find Sun's camm > api > anywhere. Can someone tell me where I can find it? Or maybe > send me a > > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm port > support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have just > a ZIP with only the .class JAR file - no source or docs), has a readme > with these comments: > > This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release.? The 2.0.3 release itself is > no longer distributed.? comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project.? The RxTx project (http://www.rxtx.org ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org) was opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support.? Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins.? Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > ? > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > I hope that is helpful! > It would be nice to work with Sun to resolve those longstanding issues. But it may not be practical unless the process goes as fast and painless as the grandfathering of commapi did. Another option may be the old kaffe extensions that moved to gnu classpathx. These don't have the native libraries but should provide the 2.0 interface and the javax.comm.properties mechansim for SPI. http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Mon Aug 4 20:23:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Mon, 04 Aug 2008 20:23:57 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4897B9BD.5070809@ergotech.com> Has there been any work/would it be possible, to layer a javacomm look-alike on top of the GNU code? The goal is not to move the javax code forward, but to emulate the "legacy" javax packages for people who still need this. Jim Trent Jarvi wrote: > On Mon, 4 Aug 2008, Bruce Boyes wrote: > >> At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible >> version of RXTX >> and Sun's comm api. I've been able to download and extract >> the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm >> api >> anywhere. Can someone tell me where I can find it? Or maybe >> send me a >> >> >> javaxcomm has had a sort of on-again off-again history. The windoze >> version has been languishing for years (literally) but there are newer >> versions for other OS's. >> >> We try to keep links on one of our help pages current: >> http://www.practicalembeddedjava.com/tools/javatools_list.html >> which gets you to here: >> http://java.sun.com/products/javacomm/ >> where it says in fact they no longer even support Windows and Mac: >> "Implementations of the API are currently available for Solaris SPARC, >> Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so >> someone could support it. But I guess that's part of the reason RXTX >> exists! >> >> So one of Sun's own products, SunSPOT, has to use RXTX to get comm port >> support. >> >> The version we use is 2.0 from 11/15/1998. I have posted it on our >> website, which is within the terms of the license agreement contained >> therein (as I understand it). >> >> The last version of javaxcomm for Windows, 2.0.3, (for which I have just >> a ZIP with only the .class JAR file - no source or docs), has a readme >> with these comments: >> >> This distribution contains the comm.jar file original part >> of the COMMAPI 2.0.3 release. The 2.0.3 release itself is >> no longer distributed. comm.jar, which contains the comm >> API java class files (eg. Sun's binary implementation of the >> interface classes), is being made available, unsupported, >> with no obligation to fix bugs, at the request of the RXTX >> project. The RxTx project (http://www.rxtx.org ), uses the >> comm.jar class files, but provides their own native library >> components to provide support for other platforms. >> >> The 2.0.3 comm.jar is being provided in this way because >> as of COMMAPI 3.x, the java binary implementation forked and >> became incompatible with the RxTx project's native code. >> Due to the lack of a clear business case, and to resource >> constraints, no additional resources are being >> provided to provide an alternative engineering solution >> at the time of writing. >> >> RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: >> >> Ultimately the COMMAPI would be better served if a Java >> Community Process JSR (http://www.jcp.org) was opened and >> the COMMAPI was rearchitected to provide a more pluggable >> framework to improve cross-platform support. Such an >> architecture would embody a better defined and better >> documented SPI interface, including a way for comm. ports >> to be revealed to the client application through the API >> via platform-aware plugins. Similarly, native code used >> to access comm port in general could be handled more >> flexibly using a plugin model, whereby on any platform, >> multiple native modules could be in use simultaneously. >> >> Since there are now various ways serial ports can be implemented >> and accessed, modular comm. port JNI native libraries would be >> of benefit insofar as removing the burden of over-generalization >> from any single native component, or inversely, by relieving the >> implicit constraint that comm. drivers be accessed only via a >> monolithic mechanism, such as the UNIX vnode interface. >> >> paul.klissner at sun.com >> 6/10/06 >> >> I hope that is helpful! >> > > It would be nice to work with Sun to resolve those longstanding issues. > But it may not be practical unless the process goes as fast and painless > as the grandfathering of commapi did. > > Another option may be the old kaffe extensions that moved to gnu > classpathx. These don't have the native libraries but should provide > the 2.0 interface and the javax.comm.properties mechansim for SPI. > > http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Mon Aug 4 21:09:15 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 21:09:15 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? Message-ID: Hi Jim, I will not step into the javax.comm namespace without Sun's explicite permission. I fully understand the pain point you are trying to address. In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm Linux) - which remains an integral part of rxtx. At the time it was a win for Sun and rxtx. The Sun commapi license is/was fairly clear that rxtx should not step into that namespace. It made sense as Sun was active in that space and rxtx may go into another namespace - it was an experiment in working with Sun. This may sound silly looking at something that happened almost 10 years ago. In a community of respect which Sun helped create, there is no question about what to do. I hope eventually Sun will step up and do a right thing too. I agree that this is hurting the API more than helping it. There are also questions about how to replace the API in the long term which includes HID support which isn't going well so far. Others that can't even look at Sun's javax.comm today and can look at Kaffe's contribution to classpathx can easily work around such restrictions. On Mon, 4 Aug 2008, Jim Redman wrote: > Has there been any work/would it be possible, to layer a javacomm > look-alike on top of the GNU code? > > The goal is not to move the javax code forward, but to emulate the > "legacy" javax packages for people who still need this. > > Jim > > Trent Jarvi wrote: >> >> It would be nice to work with Sun to resolve those longstanding issues. >> But it may not be practical unless the process goes as fast and painless >> as the grandfathering of commapi did. >> >> Another option may be the old kaffe extensions that moved to gnu >> classpathx. These don't have the native libraries but should provide >> the 2.0 interface and the javax.comm.properties mechansim for SPI. >> >> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From florianmanschwetus at gmx.de Tue Aug 5 05:04:46 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 13:04:46 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: References: <48971C1F.9020806@gmx.de> Message-ID: <489833CE.1040801@gmx.de> Just look at sendCommand in this method I have to place a Thread.sleep(20) after each byte send to get working. Even the event based receive doesn't work fine but this could be may stupidness. The specifikation document (it is on the last pages of the manual) for the beamer could be found on: http://www.optoma.co.uk/support.aspx Florian Manschwetus Trent Jarvi schrieb: > > Hi Florian > > Sorry for the top post in advance. I worry you may not see my answer > under all your code :) > > I have not received this email before. This is 500k of code which I > don't have time to read. I can spend about 5 min on each hobby email > and still get to work in the morning. I have a couple suggestions for > how to get an answer. > > First, cut out your comments and extra code so you can demonstrate the > question (I might even glance and see what is wrong then). Don't go for > a working final product. Isolate the problem using a simple program and > then ask with that as an example. If I did what you just did, I'd have > to post 3/4 of a million lines of code :) > > Second, join the rxtx mail-list and ask there. This will give you 100x > more eyes. I'll also read and try to follow. > > -- > taj > > > > On Mon, 4 Aug 2008, Florian Manschwetus wrote: > >> It could be that my university account is blocked by filters so >> resending from here. >> >> >> Topic is to control Optoma HD80 beamer using rs232 serial chat. >> This code is able to detect power state and switch the beamer on / off. >> connected is the beamer using a digitus usb 2.0 serial adapter with an >> FT232 USB-Serial adapter the systems architecture is amd64. >> >> Please take a look in the sendCommand routine i have to place theire >> those Thread.sleep to get it working. >> Now the question is this correct or is there a better way to get this >> working correctly? >> >> In the javadoc coming with the install i found this: >> setBaudBase >> >> public boolean setBaudBase(int BaudBase) >> throws UnsupportedCommOperationException, >> java.io.IOException >> >> Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 >> before using. >> >> could this explain the error? >> I attached my java source and the protocol description for the beamer >> (available on vendor website). >> >> thx, >> Florian Manschwetus >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: TestRS232.java Type: text/x-java Size: 9143 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0076.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0077.bin From michael.erskine at ketech.com Tue Aug 5 05:53:49 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Tue, 5 Aug 2008 12:53:49 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489833CE.1040801@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> > Just look at sendCommand in this method I have to place a > Thread.sleep(20) after each byte send to get working. Even the event > based receive doesn't work fine but this could be may stupidness. Hi Florian, Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. Regards, Michael Erskine. From florianmanschwetus at gmx.de Tue Aug 5 07:28:15 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:28:15 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> Message-ID: <4898556F.8000208@gmx.de> Michael Erskine schrieb: >> Just look at sendCommand in this method I have to place a >> Thread.sleep(20) after each byte send to get working. Even the event >> based receive doesn't work fine but this could be may stupidness. > > Hi Florian, > > Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. > > Regards, > Michael Erskine. > Ok, sounds fine for the receiving problem. But why i have to wait after each byte when sending a command squence? (the for loop in send command) Florian > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/284f350c/attachment-0037.bin From florianmanschwetus at gmx.de Tue Aug 5 07:44:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:44:14 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <4898592E.2020908@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >>> Just look at sendCommand in this method I have to place a >>> Thread.sleep(20) after each byte send to get working. Even the event >>> based receive doesn't work fine but this could be may stupidness. >> >> Hi Florian, >> >> Yes, naturally you'll have to wait for a response from the other end. >> Why not wait for notification from the event thread perhaps using a >> BlockingDeque rather than your LinkedList. Generally I >> try to decouple all input and output streams: in your case your >> application is operating synchronously like the "expect" program >> (http://expect.nist.gov/) so waits (or timeouts) will need to be >> factored in. >> >> Regards, >> Michael Erskine. >> > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) > > Florian Furthermore there is this basic baud with this confusing javadoc entry: public boolean setBaudBase(int BaudBase) throws UnsupportedCommOperationException, java.io.IOException Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 before using. maybe this could explain something Florian >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/006c7425/attachment-0037.bin From jredman at ergotech.com Tue Aug 5 09:13:36 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 05 Aug 2008 09:13:36 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: Message-ID: <48986E20.3060104@ergotech.com> Trent, So two issues: 1) Technically I'm still not sure how easy/practical a layer would be. The problems are always classes like listeners, and wrapping returns of gnu.io classes. I really see it as a "delegate" type of concept. Any thoughts or ideas of the practicality of this approach? The idea is not to modify RXTX. 2) Javax. The javax namespace does seem to be in widespread use outside of Sun (the same is true for the java namespace). The classpath extensions, or some other location, should be interested in a JavaComm implementation even if it does have dependencies on RXTX. Would you have any philosophical objection to an approach like that? Of course, I suspect it might be better if someone with that authority at Sun would admit that the javax namespace is already in the wild and that there is no problem with it being used within RXTX. Jim Trent Jarvi wrote: > Hi Jim, > > I will not step into the javax.comm namespace without Sun's explicite > permission. I fully understand the pain point you are trying to address. > > In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm > Linux) - which remains an integral part of rxtx. At the time it was a win for > Sun and rxtx. > > The Sun commapi license is/was fairly clear that rxtx should not step into that > namespace. It made sense as Sun was active in that space and rxtx may go into > another namespace - it was an experiment in working with Sun. > > This may sound silly looking at something that happened almost 10 years ago. > In a community of respect which Sun helped create, there is no question about > what to do. I hope eventually Sun will step up and do a right thing too. > > I agree that this is hurting the API more than helping it. There are also > questions about how to replace the API in the long term which includes HID > support which isn't going well so far. > > Others that can't even look at Sun's javax.comm today and can look at Kaffe's > contribution to classpathx can easily work around such restrictions. > > On Mon, 4 Aug 2008, Jim Redman wrote: > >> Has there been any work/would it be possible, to layer a javacomm >> look-alike on top of the GNU code? >> >> The goal is not to move the javax code forward, but to emulate the >> "legacy" javax packages for people who still need this. >> >> Jim >> >> Trent Jarvi wrote: >>> It would be nice to work with Sun to resolve those longstanding issues. >>> But it may not be practical unless the process goes as fast and painless >>> as the grandfathering of commapi did. >>> >>> Another option may be the old kaffe extensions that moved to gnu >>> classpathx. These don't have the native libraries but should provide >>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>> >>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From sandeep at genevasoftech.com Tue Aug 5 11:18:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Tue, 05 Aug 2008 22:48:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <48988B6C.5080409@genevasoftech.com> Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. *-- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/ad20f1cb/attachment-0037.html From Martin.Oberhuber at windriver.com Tue Aug 5 13:30:17 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Tue, 5 Aug 2008 21:30:17 +0200 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Sandeep, shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on Sol7 but I've successfully run it on Sol9 and Sol10. Or is your request really about a native 64bit variant? I'm afraid that then you're out of luck since I think that quite a bit of RXTX is not yet ready for 64 bit. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Sandeep Kumar K Sent: Tuesday, August 05, 2008 7:19 PM To: rxtx at qbang.org Subject: [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so for Solaris 9 Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. -- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/81b7f988/attachment-0037.html From tjarvi at qbang.org Tue Aug 5 22:38:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 22:38:34 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 5 Aug 2008, Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built > on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid that > then > you're out of luck since I think that quite a bit of RXTX is not yet > ready > for 64 bit. > While rxtx-2.1-7 probably has problems, The CVS code should be OK for 64 bit Solaris. If it isn't, let me know and I'll find which patch is missing. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Aug 5 23:13:00 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 23:13:00 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48986E20.3060104@ergotech.com> References: <48986E20.3060104@ergotech.com> Message-ID: On Tue, 5 Aug 2008, Jim Redman wrote: > Trent, > > So two issues: > > 1) Technically I'm still not sure how easy/practical a layer would be. The > problems are always classes like listeners, and wrapping returns of gnu.io > classes. I really see it as a "delegate" type of concept. Any thoughts or > ideas of the practicality of this approach? The idea is not to modify RXTX. I have not put too much thought into this. I assume you want what rxtx 2.0 provided to tie into javax.comm implementations. More classes could be added to rxtx 2.1-7 for SPI support. Maintaining rxtx-2.0 could also be handed to someone if they like. > > 2) Javax. The javax namespace does seem to be in widespread use outside of > Sun (the same is true for the java namespace). The classpath extensions, or > some other location, should be interested in a JavaComm implementation even > if it does have dependencies on RXTX. Would you have any philosophical > objection to an approach like that? > No problems. Classpathx would be a possible place to do it. I'd suggest thinking twice about what this involves in practical terms. You would be wanting to revive the 2.0 API while Sun is at 3.0 and grandfathering the JSR. This undermines the main reason (established api) for using the javax.comm namespace and does not leave such a project in a good position. The only win I see here is maintaining support for applications that can't migrate namespaces. Not that that isn't important. At some point it is going to be less work to just edit the bytecode :) Such a javax.comm effort would also be signing up new projects that decided to use the work up for concerns they probably will not understand or expect. That probably isn't a good path to facilitate for new projects at this time. We will put a good faith effort to work well with others but keep in mind the project has limited bandwidth for such efforts. > Of course, I suspect it might be better if someone with that authority at Sun > would admit that the javax namespace is already in the wild and that there is > no problem with it being used within RXTX. > > Jim > > Trent Jarvi wrote: >> Hi Jim, >> >> I will not step into the javax.comm namespace without Sun's explicite >> permission. I fully understand the pain point you are trying to address. >> >> In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java >> Comm Linux) - which remains an integral part of rxtx. At the time it was a >> win for Sun and rxtx. >> >> The Sun commapi license is/was fairly clear that rxtx should not step into >> that namespace. It made sense as Sun was active in that space and rxtx may >> go into another namespace - it was an experiment in working with Sun. >> >> This may sound silly looking at something that happened almost 10 years >> ago. In a community of respect which Sun helped create, there is no >> question about what to do. I hope eventually Sun will step up and do a >> right thing too. >> >> I agree that this is hurting the API more than helping it. There are also >> questions about how to replace the API in the long term which includes HID >> support which isn't going well so far. >> >> Others that can't even look at Sun's javax.comm today and can look at >> Kaffe's contribution to classpathx can easily work around such >> restrictions. >> >> On Mon, 4 Aug 2008, Jim Redman wrote: >> >>> Has there been any work/would it be possible, to layer a javacomm >>> look-alike on top of the GNU code? >>> >>> The goal is not to move the javax code forward, but to emulate the >>> "legacy" javax packages for people who still need this. >>> >>> Jim >>> >>> Trent Jarvi wrote: >>>> It would be nice to work with Sun to resolve those longstanding issues. >>>> But it may not be practical unless the process goes as fast and painless >>>> as the grandfathering of commapi did. >>>> >>>> Another option may be the old kaffe extensions that moved to gnu >>>> classpathx. These don't have the native libraries but should provide >>>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>>> >>>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From sandeep at genevasoftech.com Wed Aug 6 00:03:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Wed, 06 Aug 2008 11:33:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: <48993EB8.30107@genevasoftech.com> Thank you Mr. Martin for your suggestion. The native file which is given in rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am getting the following error . Any suggestions to solve this issue. I am using Solaris SPARC 64 bit machine. ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) thrown while loading gnu.io.RXTXCommDriver Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(Unknown Source) at java.lang.ClassLoader.loadLibrary(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) at com.ReadFromModem.main(ReadFromModem.java:84) * * *Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid > that then > you're out of luck since I think that quite a bit of RXTX is not yet ready > for 64 bit. > > Cheers, > -- > *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > ------------------------------------------------------------------------ > *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On > Behalf Of *Sandeep Kumar K > *Sent:* Tuesday, August 05, 2008 7:19 PM > *To:* rxtx at qbang.org > *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so > for Solaris 9 > > Hi, > > Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 > bit machine. The librxtxSerial.so given in website is for Solaris 8. > > *-- > > Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/1e920343/attachment-0037.html From tjarvi at qbang.org Wed Aug 6 00:21:42 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 00:21:42 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <48993EB8.30107@genevasoftech.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> <48993EB8.30107@genevasoftech.com> Message-ID: Hi Sandeep You may be out of luck unless you can compile the 2.1 src in CVS (requires gnu make and gcc). But you could try the ToyBox(R)(TM) which is a collection of WiLdLy untested cross compiled 2.1-7 binaries covering everything from the ibm z series to embeded arm/ppc. To give an idea how poorly these are tested, I don't even know if z series machines have a serial port. ftp://www.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Solaris They should at least match the binary types. Actually, I think if you use the rxtx jar from CVS with that file, it should 'work' as the fix for 64 bits was in java not the native code. You could just cd rxtx*/src; javac *.java then jar -cf RXTXcomm.jar `find -name \*.class` to create the hybrid which will complain about version information a bit. On Wed, 6 Aug 2008, Sandeep Kumar K wrote: > Thank you Mr. Martin for your suggestion. The native file which is given in > rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am > getting the following error . > Any suggestions to solve this issue. > I am using Solaris SPARC 64 bit machine. > > ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar > java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 > (Possible cause: architecture word > width mismatch) thrown while loading gnu.io.RXTXCommDriver > Exception in thread "main" java.lang.UnsatisfiedLinkError: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF > class: ELFCLASS64 (Possible cause: > architecture word width mismatch) > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(Unknown Source) > at java.lang.ClassLoader.loadLibrary(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > at com.ReadFromModem.main(ReadFromModem.java:84) > > * > * > > *Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > > > Oberhuber, Martin wrote: >> Sandeep, >> shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse >> variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on >> Sol7 but I've successfully run it on Sol9 and Sol10. >> Or is your request really about a native 64bit variant? I'm afraid that >> then >> you're out of luck since I think that quite a bit of RXTX is not yet ready >> for 64 bit. >> Cheers, >> -- >> *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> ------------------------------------------------------------------------ >> *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On >> Behalf Of *Sandeep Kumar K >> *Sent:* Tuesday, August 05, 2008 7:19 PM >> *To:* rxtx at qbang.org >> *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so >> for Solaris 9 >> >> Hi, >> >> Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 >> bit machine. The librxtxSerial.so given in website is for Solaris 8. >> >> *-- >> Thanks & Regards >> >> Sandeep Kumar K >> Sr. Software Engineer >> Geneva Software Technologies >> Whitefield, Bangalore >> Mob : 9880193454* >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> From michael.erskine at ketech.com Wed Aug 6 01:39:28 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 6 Aug 2008 08:39:28 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Florian Manschwetus wrote: > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) Hi Florian, I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. Regards, Michael Erskine. From florianmanschwetus at gmx.de Wed Aug 6 02:53:16 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 06 Aug 2008 10:53:16 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Message-ID: <4899667C.6010706@gmx.de> Michael Erskine schrieb: > Florian Manschwetus wrote: >> Ok, sounds fine for the receiving problem. >> But why i have to wait after each byte when sending a command squence? >> (the for loop in send command) > > Hi Florian, > I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. > > Regards, > Michael Erskine. > correct with a terminal on the other end it works, my idea was that this basic baud has some influence. Could some one explain what it is for? Florian > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/c2b4fa84/attachment-0037.bin From rick_knight at rlknight.com Wed Aug 6 13:01:07 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:01:07 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F4F3.3020707@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > I have an application (Readerware) that uses RXTX with Javax to access the serial port. This used to work fine under previous Linux' and Java, but something has changed, I assume with Java itself , that is causing the application to fail with a link error. The application is not able to find librxtxSerialParallel.so. RXTX supplies librxtxSerial.so and librxtxParallel.so, but not librxtxSerialParallel.so. Where can I get librxtxSerialParallel.so, or do I need it? Is something else causing the lib to not be found? Thanks, Rick Knight From rick_knight at rlknight.com Wed Aug 6 13:17:55 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:17:55 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F8E3.5060400@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Thanks for the reply. The developer of the app I'm trying to use (Readerware) has sent me a copy of the comm.api and I've copied the library (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar into the proper places. When I try to run the application, I get this error... Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: /usr/lib/libSolarisSerialParallel.so: /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not little-endian (Possible cause: endianness mismatch) Caught java.lang.UnsatisfiedLinkError: com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I while loading driver com.sun.comm.SolarisDriver Is there a way around this error? Thanks again, Rick Knight From jlar310 at gmail.com Wed Aug 6 13:37:42 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 14:37:42 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899F8E3.5060400@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > The developer of the app I'm trying to use (Readerware) has sent me a > copy of the comm.api and I've copied the library > (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar > into the proper places. When I try to run the application, I get this > error... > > Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: > /usr/lib/libSolarisSerialParallel.so: > /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not > little-endian (Possible cause: endianness mismatch) > Caught java.lang.UnsatisfiedLinkError: > com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I > > while loading driver com.sun.comm.SolarisDriver > > Is there a way around this error? What host OS are you running? From your original post it looks like 32 bit Linux. The libSolarisSerialParallel.so file is for Sun Solaris and will vary depending on the underlying hardware architecture as well. Sorry for the double post Rick, but I failed to send this to the list the first time... -- Jeff From rick_knight at rlknight.com Wed Aug 6 13:44:29 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:44:29 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: <4899FF1D.9030504@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > > >> The developer of the app I'm trying to use (Readerware) has sent me a >> copy of the comm.api and I've copied the library >> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >> into the proper places. When I try to run the application, I get this >> error... >> >> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >> /usr/lib/libSolarisSerialParallel.so: >> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >> little-endian (Possible cause: endianness mismatch) >> Caught java.lang.UnsatisfiedLinkError: >> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >> >> while loading driver com.sun.comm.SolarisDriver >> >> Is there a way around this error? >> > > What host OS are you running? From your original post it looks like 32 > bit Linux. > > The libSolarisSerialParallel.so file is for Sun Solaris and will vary > depending on the underlying hardware architecture as well. > > I'm running Kubuntu Linux (debian based). It's 32 bit. Rick Knight From jlar310 at gmail.com Wed Aug 6 15:33:23 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 16:33:23 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > I don't think Sun did binary libraries for Linux in the 2.0 version. Can someone with more historical experience than I confirm that? I recently tried to port a Comm API application from Solaris sparc to Linux x86 and likewise could not get my hands on the binary libraries. I eventually just re-wrote the code to use the gnu namespace packages and rxtx 2.1. What I don't understand is why your application vendor does not provide everything you need to run their software. FYI: I have librxtxParallel.so and librxtxSerial.so installed at JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is /usr/java/default which is actually a softlink to /usr/java/jre1.6.0_05. -- Jeff From defiantlew at yahoo.com.au Wed Aug 6 16:29:33 2008 From: defiantlew at yahoo.com.au (Lew L) Date: Thu, 7 Aug 2008 08:29:33 +1000 Subject: [Rxtx] Sun's Comm API Documentation References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> Message-ID: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> As a matter of interest is the Sun Comm API documentation available somewhere? I have tried the Sun site but it seems to have been removed. Unless I have missed the documentation for RXTX? I javadocced the RXTX source but information (to me) is minimal. Somewhere I got the impression that the Sun Comm API docs is, or was, compatible with RXTX, what is the best docs to use in conjuntion with RXTX and where may the be available? Cheers Lew From rick_knight at rlknight.com Wed Aug 6 17:18:33 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:18:33 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A3149.4050306@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff I'm not sure if I posted this here or not, but when I try to build RXTX from source I get this install error... make all-am make[1]: Entering directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' make[1]: Nothing to be done for `all-am'. make[1]: Leaving directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 Can you tell me how to get past this error and get RXTX built and installed? Thanks, Rick From bboyes at systronix.com Wed Aug 6 17:40:12 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Wed, 06 Aug 2008 17:40:12 -0600 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: At 16:29 08/06/2008, Lew L wrote: >As a matter of interest is the Sun Comm API documentation available >somewhere? I have tried the Sun site but it seems to have been removed. It's in the file we have posted, link in prev email (sorry, in a huge hurry right now). Javadocs definitely there. >Unless I have missed the documentation for RXTX? I javadocced the RXTX >source but information (to me) is minimal. >Somewhere I got the impression that the Sun Comm API docs is, or was, >compatible with RXTX, what is the best docs to use in conjuntion with RXTX >and where may the be available? Yeah, this is one of my concerns/beefs. There is little documentation for RXTX and it isn't just the same as javaxcomm. I would be willing to help out writing docs for RXTX! Yes really... esp if we can fix the Bluetooth issues. best regards Bruce >Cheers >Lew > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx ------- WWW.SYSTRONIX.COM ---------- Real embedded Java and much more +1-801-534-1017 Salt Lake City, USA From rick_knight at rlknight.com Wed Aug 6 17:54:08 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:54:08 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A39A0.2090309@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff, I would like for my vendor to switch to rxtx 2.1. It would make things much easier for me. I'm not sure why he's still using the javax compatible code. He's a small operation. Re-writing the code to use gnu namespace sounds like a major overhaul. Was it? Thanks, Rick From tjarvi at qbang.org Wed Aug 6 21:35:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:35:12 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: >> >>> Jeff wrote: >>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>>> >>>> >>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things > much easier for me. I'm not sure why he's still using the javax > compatible code. He's a small operation. Re-writing the code to use gnu > namespace sounds like a major overhaul. Was it? > Hi Jeff, The changes are fairly mechanical. Imports need to change and any explicite use of the namespace needs to change such as catching an exception. The following script was made for maintaining rxtx 2.0 but can apply to other needs. It is in the contrib dir with rxtx source. #!/bin/sh # Don't use! :) # # Sat, 03 May 2003 16:45:08 Modifications from J?rg Weule # Create a ed-cmd for the change of one pattern # case $1 in gnu) X=g/javax_comm/s+javax_comm+gnu_io+g ;; javax) X=g/gnu_io/s+gnu_io+javax_comm+g ;; *) echo;echo;echo From the top rxtx directory run;echo;echo -e \\t./ChangePackage.sh gnu;echo -e \\t\\tor;echo -e \\t./ChangePackage.sh javax;echo;echo; exit 0 ;; esac # # ed will be used to keep the owner and mode of the files unchanged. # We have run the ed-script for the characters '.' '/' as well. # "tr _ $D" do the change. # find . -type f -a -print | grep -v $0 | (while read F ; do ( echo $X; echo $X| tr _ /; echo $X| tr _ .; echo w; echo q ) | ed $F 2>&1 >/dev/null done ) # # Now we do little changes at the Makefiles. Hope that all we need. # find . -name Makefile\* -a -print | (while read F ; do cat < References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: On Thu, 7 Aug 2008, Lew L wrote: > As a matter of interest is the Sun Comm API documentation available > somewhere? I have tried the Sun site but it seems to have been removed. > > Unless I have missed the documentation for RXTX? I javadocced the RXTX > source but information (to me) is minimal. > Somewhere I got the impression that the Sun Comm API docs is, or was, > compatible with RXTX, what is the best docs to use in conjuntion with RXTX > and where may the be available? > Hi Lew, The documentation on Sun's website is accurate. The changes that are problematic in 3.0 are on the backside which rxtx used to plug into. http://java.sun.com/products/javacomm/reference/api/index.html CommPortIdentifier may have some minor differences (judging by the authors notes). -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Aug 6 21:46:08 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:46:08 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > If javax.comm.properties is properly installed and you are using a 2.0 version of Sun's commapi with rxtx 2.0, you should not see the library attempt to load libSolarisSerialParallel.so. Sun CommAPI 3.0 will not work with any version of rxtx as it is hard coded to use the shared library. See the INSTALL file with rxtx-2.0 source for more help with the properties file. -- Trent Jarvi tjarvi at qbang.org From jlar310 at gmail.com Thu Aug 7 06:32:06 2008 From: jlar310 at gmail.com (Jeff) Date: Thu, 7 Aug 2008 07:32:06 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > Jeff wrote: >> >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >> wrote: >> >>> >>> Jeff wrote: >>> >>>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>> wrote: >>>> >>>> >>>> >>>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things much > easier for me. I'm not sure why he's still using the javax compatible code. > He's a small operation. Re-writing the code to use gnu namespace sounds like > a major overhaul. Was it? I found it quite easy. In fact, in order to accommodate the transition, I actually separated all of the code that deals directly with the Comm API or RXTX into a helper class. The helper class was then coded to use reflection to determine which library was available and then instantiate the necessary objects. No direct imports of either library are used. The main application just needs to get it's hands on the IO streams and need not deal directly with the libraries. Other programs may not be so simple... But this doesn't really help you unless your vendor forks over the source code... -- Jeff From rick_knight at rlknight.com Thu Aug 7 09:47:12 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Thu, 07 Aug 2008 08:47:12 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: <489B1900.10108@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >>> wrote: >>> >>> >>>> Jeff wrote: >>>> >>>> >>>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>>> copy of the comm.api and I've copied the library >>>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>>> into the proper places. When I try to run the application, I get this >>>>>> error... >>>>>> >>>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>>> /usr/lib/libSolarisSerialParallel.so: >>>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>>> little-endian (Possible cause: endianness mismatch) >>>>>> Caught java.lang.UnsatisfiedLinkError: >>>>>> >>>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>>> >>>>>> while loading driver com.sun.comm.SolarisDriver >>>>>> >>>>>> Is there a way around this error? >>>>>> >>>>>> >>>>>> >>>>> What host OS are you running? From your original post it looks like 32 >>>>> bit Linux. >>>>> >>>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>>> depending on the underlying hardware architecture as well. >>>>> >>>>> >>>>> >>>>> >>>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>>> >>>> >>>> >>> I don't think Sun did binary libraries for Linux in the 2.0 version. >>> Can someone with more historical experience than I confirm that? >>> >>> I recently tried to port a Comm API application from Solaris sparc to >>> Linux x86 and likewise could not get my hands on the binary libraries. >>> I eventually just re-wrote the code to use the gnu namespace packages >>> and rxtx 2.1. >>> >>> What I don't understand is why your application vendor does not >>> provide everything you need to run their software. >>> >>> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >>> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >>> /usr/java/default which is actually a softlink to >>> /usr/java/jre1.6.0_05. >>> >>> >>> >> Jeff, >> >> I would like for my vendor to switch to rxtx 2.1. It would make things much >> easier for me. I'm not sure why he's still using the javax compatible code. >> He's a small operation. Re-writing the code to use gnu namespace sounds like >> a major overhaul. Was it? >> > > I found it quite easy. In fact, in order to accommodate the > transition, I actually separated all of the code that deals directly > with the Comm API or RXTX into a helper class. The helper class was > then coded to use reflection to determine which library was available > and then instantiate the necessary objects. No direct imports of > either library are used. The main application just needs to get it's > hands on the IO streams and need not deal directly with the libraries. > Other programs may not be so simple... > > But this doesn't really help you unless your vendor forks over the > source code... > > Jeff, This may not help me directly, but I'm going to forward this thread to the vendor. I think he'll be open to making things work. Thanks again, Rick Knight From agusmunioz at gmail.com Thu Aug 7 16:39:51 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Thu, 7 Aug 2008 19:39:51 -0300 Subject: [Rxtx] How to send ack? Message-ID: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Hi, I'm still learning about serial communication and I have some doubts. I've got this question about how to do the following thing in rxtx. I have this hardware that connect to a PC using a serial port. These hardware receives data from a telephone line, proccess it, and then send it forward to the serial port. I've used a program named wincomm that shows what information is send it through the serial port and I have the nex behaviour: The hardware has a buffer where all data is stored, that cannot be sent it through the seria port. The program reads the first data send it by the hardware, and keep reading the same data always. There is a button in the application that says enable Ack, and when I click, then the hardware start to send all the stored information, and all the information is shown. I write a class, using rxtx that reads the serial port, and the same thing happens, it remains reading the same (first) data all the time. And I thing something like the enable Ack I'm missing. How can I do this enable Ack from my java code using rxtx? Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080807/e0a0f9a1/attachment-0035.html From ajmas at sympatico.ca Thu Aug 7 18:26:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 7 Aug 2008 20:26:41 -0400 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: <4BF42297-81E2-4BB8-A89F-1D43588379AE@sympatico.ca> On 6-Aug-08, at 19:40 , Bruce Boyes wrote: >> Unless I have missed the documentation for RXTX? I javadocced the >> RXTX >> source but information (to me) is minimal. >> Somewhere I got the impression that the Sun Comm API docs is, or was, >> compatible with RXTX, what is the best docs to use in conjuntion >> with RXTX >> and where may the be available? > > Yeah, this is one of my concerns/beefs. There is little documentation > for RXTX and it isn't just the same as javaxcomm. > > I would be willing to help out writing docs for RXTX! Yes really... > esp if we can fix the Bluetooth issues. If you want to contribute documentation then the best place to do that is the wiki. If there is anything missing or that could be improved on then please do so. If there are any points that you would like to see improved, for which you don't have the knowledge then ask on the mailing list for a volunteer. Andre From florianmanschwetus at gmx.de Fri Aug 8 03:04:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Fri, 08 Aug 2008 11:04:14 +0200 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Message-ID: <489C0C0E.2020401@gmx.de> Agustin Mu?oz schrieb: > Hi, I'm still learning about serial communication and I have some > doubts. I've got this question about how to do the following thing in rxtx. > I have this hardware that connect to a PC using a serial port. These > hardware receives data from a telephone line, proccess it, and then send > it forward to the serial port. I've used a program named wincomm that > shows what information is send it through the serial port and I have the > nex behaviour: > > The hardware has a buffer where all data is stored, that cannot be sent > it through the seria port. > The program reads the first data send it by the hardware, and keep > reading the same data always. > There is a button in the application that says enable Ack, and when I > click, then the hardware start to send all the stored information, and > all the information is shown. > > I write a class, using rxtx that reads the serial port, and the same > thing happens, it remains reading the same (first) data all the time. > And I thing something like the enable Ack I'm missing. > How can I do this enable Ack from my java code using rxtx? Afaik, a look at man ascii reveals: Okt Dez Hex Char 006 6 06 ACK So, i hope this will do the job: send(6); florian > > Thanks in advance > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/5b4965f8/attachment-0035.bin From agusmunioz at gmail.com Fri Aug 8 16:31:00 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 19:31:00 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <489C0C0E.2020401@gmx.de> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> Message-ID: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Hi Florian, thanks for the answer. By send(6) you mean to get the port OutputStream and write a 6? I try that but it didn't work. Any suggestion? Thanks On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < florianmanschwetus at gmx.de> wrote: > Agustin Mu?oz schrieb: > > Hi, I'm still learning about serial communication and I have some doubts. >> I've got this question about how to do the following thing in rxtx. >> I have this hardware that connect to a PC using a serial port. These >> hardware receives data from a telephone line, proccess it, and then send it >> forward to the serial port. I've used a program named wincomm that shows >> what information is send it through the serial port and I have the nex >> behaviour: >> >> The hardware has a buffer where all data is stored, that cannot be sent >> it through the seria port. >> The program reads the first data send it by the hardware, and keep reading >> the same data always. >> There is a button in the application that says enable Ack, and when I >> click, then the hardware start to send all the stored information, and all >> the information is shown. >> >> I write a class, using rxtx that reads the serial port, and the same thing >> happens, it remains reading the same (first) data all the time. And I thing >> something like the enable Ack I'm missing. >> How can I do this enable Ack from my java code using rxtx? >> > Afaik, a look at man ascii reveals: > Okt Dez Hex Char > 006 6 06 ACK > So, i hope this will do the job: > send(6); > > florian > >> >> Thanks in advance >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/7f3fba42/attachment-0034.html From agusmunioz at gmail.com Fri Aug 8 18:39:27 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 21:39:27 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Message-ID: <988288430808081739x7f9e7889id82591d5a9e2b4f6@mail.gmail.com> Ok, Florian, it works!! my problem was that I've been sending, through the OutputStream, the bytes of 6 as a string: out.write("6".getBytes()); but then I realized that you can write an int on an OuptuStream, so I tried that and It works: out.write(6); Thank you for the guidance!! On Fri, Aug 8, 2008 at 7:31 PM, Agustin Mu?oz wrote: > Hi Florian, thanks for the answer. By send(6) you mean to get the port > OutputStream and write a 6? > > I try that but it didn't work. > > Any suggestion? > > Thanks > > > On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < > florianmanschwetus at gmx.de> wrote: > >> Agustin Mu?oz schrieb: >> >> Hi, I'm still learning about serial communication and I have some doubts. >>> I've got this question about how to do the following thing in rxtx. >>> I have this hardware that connect to a PC using a serial port. These >>> hardware receives data from a telephone line, proccess it, and then send it >>> forward to the serial port. I've used a program named wincomm that shows >>> what information is send it through the serial port and I have the nex >>> behaviour: >>> >>> The hardware has a buffer where all data is stored, that cannot be sent >>> it through the seria port. >>> The program reads the first data send it by the hardware, and keep >>> reading the same data always. >>> There is a button in the application that says enable Ack, and when I >>> click, then the hardware start to send all the stored information, and all >>> the information is shown. >>> >>> I write a class, using rxtx that reads the serial port, and the same >>> thing happens, it remains reading the same (first) data all the time. And I >>> thing something like the enable Ack I'm missing. >>> How can I do this enable Ack from my java code using rxtx? >>> >> Afaik, a look at man ascii reveals: >> Okt Dez Hex Char >> 006 6 06 ACK >> So, i hope this will do the job: >> send(6); >> >> florian >> >>> >>> Thanks in advance >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/b918ab3d/attachment-0034.html From florianmanschwetus at gmx.de Sat Aug 9 00:45:43 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Sat, 09 Aug 2008 08:45:43 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4899667C.6010706@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> Message-ID: <489D3D17.9090209@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >> Florian Manschwetus wrote: >>> Ok, sounds fine for the receiving problem. >>> But why i have to wait after each byte when sending a command squence? >>> (the for loop in send command) >> >> Hi Florian, >> I'd imagine you probably don't! You could send all bytes in one go and >> RXTX would send them. The problem is most probably the other end: >> perhaps it has a really small buffer, some non-standard UART, or a >> crazy timing issue. If you attach a terminal to your output and send >> all the bytes of a command in one go they should appear no problem. >> >> Regards, >> Michael Erskine. >> > correct with a terminal on the other end it works, my idea was that this > basic baud has some influence. Could some one explain what it is for? > > Florian To make it more clear, my problem is that i can't use: outputStream.write(byte[]); => Beamer doesn't understand the sequence. (mostly no answer when he answers then *001) when i use this construct instead: for (int i = 0; i < command.length; i++) { this.outputStream.write(command[i]); try { Thread.sleep(25); } catch (InterruptedException e) { // TODO Auto-generated catch block e.printStackTrace(); } } it works nearly reliable. So what could it be? This Basic Baud is what exactly? Florian -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080809/692304ee/attachment-0034.bin From tjarvi at qbang.org Sat Aug 9 16:37:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Aug 2008 16:37:19 -0600 (MDT) Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489D3D17.9090209@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> <489D3D17.9090209@gmx.de> Message-ID: On Sat, 9 Aug 2008, Florian Manschwetus wrote: > Florian Manschwetus schrieb: >> Michael Erskine schrieb: >>> Florian Manschwetus wrote: >>>> Ok, sounds fine for the receiving problem. >>>> But why i have to wait after each byte when sending a command squence? >>>> (the for loop in send command) >>> >>> Hi Florian, >>> I'd imagine you probably don't! You could send all bytes in one go and >>> RXTX would send them. The problem is most probably the other end: perhaps >>> it has a really small buffer, some non-standard UART, or a crazy timing >>> issue. If you attach a terminal to your output and send all the bytes of a >>> command in one go they should appear no problem. >>> >>> Regards, >>> Michael Erskine. >>> >> correct with a terminal on the other end it works, my idea was that this >> basic baud has some influence. Could some one explain what it is for? >> >> Florian > To make it more clear, > my problem is that i can't use: > outputStream.write(byte[]); > => Beamer doesn't understand the sequence. (mostly no answer when he answers > then *001) > > when i use this construct instead: > > for (int i = 0; i < command.length; i++) { > this.outputStream.write(command[i]); > try { > Thread.sleep(25); > } catch (InterruptedException e) { > // TODO Auto-generated catch block > e.printStackTrace(); > } > } > > it works nearly reliable. > > So what could it be? This Basic Baud is what exactly? > I suspect you are using the 'moon protocol' and don't know it. RXTX enables this by default. The buffer on the other end is first in first out while reading. If the buffer is full, the bits are hand carried to the moon and burried. Then if the other side reads a couple bytes, two more bytes go into the buffer followed by more moon protocol. The resulting array of bytes the other side reads may appear to be scrambled until you go to the moon, get the bits and insert them in the right place. Flow control can prevent the default moon protocol and throttles the communiation by almost writing a byte at a time as need be. Hardware flow control is preferable but software flow control should also work. Read and write can appear to hang if the other side is not connected. This is why we don't enable them all the time. If you can't use flow control, you have to take care with the moon protocol and give the other side time to read. That is what your slower version of write is doing. -- Trent Jarvi tjarvi at qbang.org From rxtx at allenjb.me.uk Mon Aug 11 08:06:36 2008 From: rxtx at allenjb.me.uk (AllenJB) Date: Mon, 11 Aug 2008 15:06:36 +0100 Subject: [Rxtx] Disabling EV_RXFLAG Message-ID: <48A0476C.2090800@allenjb.me.uk> Hi all, I'm working with a device which does not use an EvtChar and need to disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an event mask of FD 01 00 00. The reference software I have uses FB 00 00 00. With the rxtx mask I get framing errors which I believe are caused when the EvtChar is received. Is there currently a way with rxtx (I've using rxtx from Java) to disable EV_RXFLAG? If not from Java, where would I start if I wanted to turn the EV_RXFLAG option off in the C code? I've had a grep of the rxtx source code, but I can't see where EV_RXFLAG is being set. Thanks in advance, AllenJB From tjarvi at qbang.org Mon Aug 11 14:17:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Aug 2008 14:17:27 -0600 (MDT) Subject: [Rxtx] Disabling EV_RXFLAG In-Reply-To: <48A0476C.2090800@allenjb.me.uk> References: <48A0476C.2090800@allenjb.me.uk> Message-ID: On Mon, 11 Aug 2008, AllenJB wrote: > Hi all, > > I'm working with a device which does not use an EvtChar and need to > disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an > event mask of FD 01 00 00. The reference software I have uses FB 00 00 > 00. With the rxtx mask I get framing errors which I believe are caused > when the EvtChar is received. > > Is there currently a way with rxtx (I've using rxtx from Java) to > disable EV_RXFLAG? > > If not from Java, where would I start if I wanted to turn the EV_RXFLAG > option off in the C code? I've had a grep of the rxtx source code, but I > can't see where EV_RXFLAG is being set. > > Thanks in advance, > > AllenJB Hi Allen, I'd look at termios.c::tcsetattr() and termios.c::FillDCB() -- Trent Jarvi tjarvi at qbang.org From superdadusa at gmail.com Tue Aug 12 13:57:32 2008 From: superdadusa at gmail.com (John Choi) Date: Tue, 12 Aug 2008 13:57:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. Message-ID: Hi all, Just let you all know I just start to learn Java. I have download the serial comm package and the source code from open source communities.. I was able to verify with the given message string via serial monitor. when the given message string sends to the serial port then the character return added to the end of string by default if I use "Hello World" however if I changed to something else other than "Hello, World" there is no character return add to the end of string. I thing the library download from rxtx.org has implemented for the special strings. I can do like "login\n" in the string message to make character return but I don't want to add this individual custom character for each command return in every static message string I send, Can any who have done this might help me? Basically, something like this,, Write and add function to the program write a command, Reads the respond from a serial device.. Function handles multiple messages, Write: "com open" Read: Welcome to my world" expected Write: "admin" Read: Password?, expected Write: "admin" Read: you are successfully login terminal, expected. And I need to add a separate function handler handles a character return add to the each command above. If anyone can help this I can do the reset? Thank you in advance, John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0030.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SerialIO.java Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0030.pl From Steffen.DETTMER at ingenico.com Wed Aug 13 02:16:38 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 13 Aug 2008 10:16:38 +0200 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: References: Message-ID: <20080813081638.GA25412@elberon.bln.de.ingenico.com> * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > I can do like "login\n" in the string message to make character > return but I don't want to add this individual custom character > for each command return in every static message string I send, and why not?! > Can any who have done this might help me? what's about with writing a small wrapper function adding the carriage return? However, this would be slow, because either you call write two times (very bad) or the string needs to be copied, \n appended and written (since you are using Java Performance probably isn't so critical). Personally I would write `"login\n"' and `username + "\n"' etc., because since it is part of the command it should be part of the command definition string. > Basically, something like this,, Write and add function to the program write > a command, Reads the respond from a serial device.. correctly reading a `line' is more difficult. If you cannot make assumptions about timeouts and/or you need to have low delay, you need to read byte wise. If you need to save CPU resources you might need to add some buffering layer that you can read byte-wise but that is reading blockwise with some small timeout (lets say for serial lines something around byte transmission time times three or so). > /* > * To change this template, choose Tools | Templates > * and open the template in the editor. > */ :) > package joliba; > > /** > * > * @author root > */ :) > // derived from SUN's examples in the javax.comm package > import java.io.*; > import java.util.*; > //import javax.comm.*; // for SUN's serial/parallel port libraries > import gnu.io.*; // for rxtxSerial library > > public class SerialIO implements Runnable, SerialPortEventListener { > static CommPortIdentifier portId; > static CommPortIdentifier saveportId; > static Enumeration portList; > InputStream inputStream; > SerialPort serialPort; > Thread readThread; You need a thread for your synchronous RPC-style protocol? > static String messageString = "Hello, world!"; > static OutputStream outputStream; > static boolean outputBufferEmptyFlag = false; > > public static void main(String[] args) { > boolean portFound = false; > String defaultPort; > > // determine the name of the serial port on several operating systems > String osname = System.getProperty("os.name","").toLowerCase(); > if ( osname.startsWith("windows") ) { > // windows > defaultPort = "COM1"; > } else if (osname.startsWith("linux")) { > // linux > defaultPort = "/dev/ttyS0"; > } else if ( osname.startsWith("mac") ) { > // mac > defaultPort = "????"; > } else { > System.out.println("Sorry, your operating system is not supported"); > return; > } Is such a construction recommended? Isn't there some abstraction (like COM1 working on any platform)? [...] > try { > // activate the OUTPUT_BUFFER_EMPTY notifier > serialPort.notifyOnOutputEmpty(true); > } catch (Exception e) { > System.out.println("Error setting event notification"); > System.out.println(e.toString()); > System.exit(-1); > } I doubt that -1 is defined, probably some 127 or so would be the result, maybe better simply `throw e'? > public void writetoport() { > System.out.println("Writing \""+messageString+"\" to "+serialPort.getName()); > try { > // write string to serial port > outputStream.write(messageString.getBytes()); > } catch (IOException e) {} > } maybe something like /** * Writes the given output string and an additional carriage * return to the current outputStream. */ public void writeStringToPort( /** The output string (without CR). */ String output ) throws IOException { String outputLine = output + "\n"; outputStream.write(outputLine.getBytes()); } ? > > public SerialIO() { > // initalize serial port > try { > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > } catch (PortInUseException e) {} if the port is in use, you continue? Wonder that this works in Java, I would assume serialPort beeing uninitialized which AFAIK is an error in Java. > try { > inputStream = serialPort.getInputStream(); > } catch (IOException e) {} > > try { > serialPort.addEventListener(this); > } catch (TooManyListenersException e) {} > > // activate the DATA_AVAILABLE notifier > serialPort.notifyOnDataAvailable(true); > > try { > // set port parameters > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > } catch (UnsupportedCommOperationException e) {} > > // start the read thread > readThread = new Thread(this); > readThread.start(); > > } I think in all those exception cases you can abort, because it is unlikely that ignoring those errors allow a successful continuation, so in this case maybe it would be better to add a throw clause to the method. > public void run() { > // first thing in the thread, we initialize the write operation > initwritetoport(); > try { > while (true) { > // write string to port, the serialEvent will read it > writetoport(); > Thread.sleep(1000); > } > } catch (InterruptedException e) {} > } Does this make sense? Your `SimpleReadApp' writes one and the same string each second? > public void serialEvent(SerialPortEvent event) { > switch (event.getEventType()) { > case SerialPortEvent.BI: > case SerialPortEvent.OE: > case SerialPortEvent.FE: > case SerialPortEvent.PE: > case SerialPortEvent.CD: > case SerialPortEvent.CTS: > case SerialPortEvent.DSR: > case SerialPortEvent.RI: > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > break; > case SerialPortEvent.DATA_AVAILABLE: > // we get here if data has been received > byte[] readBuffer = new byte[20]; > try { > // read data > while (inputStream.available() > 0) { > int numBytes = inputStream.read(readBuffer); > } > // print data > String result = new String(readBuffer); > System.out.println("Read: "+result); > } catch (IOException e) {} I doubt that this is correct. I would assume you will get a 20 bytes result always, if more bytes would be available they would be printed in a second line but if less bytes are read I'd assume that the buffer/result contains zero bytes from implicite readBuffer contents initialisation (zero is no string terminator in Java AFAIK). > break; > } > } > } oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From florianmanschwetus at gmx.de Wed Aug 13 06:09:31 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 13 Aug 2008 14:09:31 +0200 Subject: [Rxtx] someone has seen such errors? Message-ID: <48A2CEFB.90007@gmx.de> I mean my communication mostly works, but it is far from perfect could this be the reason? Florian Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/949b9947/attachment-0030.bin From superdadusa at gmail.com Wed Aug 13 08:40:32 2008 From: superdadusa at gmail.com (John Choi) Date: Wed, 13 Aug 2008 08:40:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: <20080813081638.GA25412@elberon.bln.de.ingenico.com> References: <20080813081638.GA25412@elberon.bln.de.ingenico.com> Message-ID: Thank you so much Steffen and I will try that suggestion. John On 8/13/08, Steffen DETTMER wrote: > > * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > > I can do like "login\n" in the string message to make character > > return but I don't want to add this individual custom character > > for each command return in every static message string I send, > > and why not?! > > > Can any who have done this might help me? > > what's about with writing a small wrapper function adding the > carriage return? > However, this would be slow, because either you call write two > times (very bad) or the string needs to be copied, \n appended > and written (since you are using Java Performance probably isn't > so critical). > > Personally I would write `"login\n"' and `username + "\n"' etc., > because since it is part of the command it should be part of the > command definition string. > > > Basically, something like this,, Write and add function to the program > write > > a command, Reads the respond from a serial device.. > > correctly reading a `line' is more difficult. If you cannot make > assumptions about timeouts and/or you need to have low delay, you > need to read byte wise. If you need to save CPU resources you > might need to add some buffering layer that you can read > byte-wise but that is reading blockwise with some small timeout > (lets say for serial lines something around byte transmission > time times three or so). > > > /* > > * To change this template, choose Tools | Templates > > * and open the template in the editor. > > */ > > :) > > > package joliba; > > > > /** > > * > > * @author root > > */ > > :) > > > // derived from SUN's examples in the javax.comm package > > import java.io.*; > > import java.util.*; > > //import javax.comm.*; // for SUN's serial/parallel port libraries > > import gnu.io.*; // for rxtxSerial library > > > > public class SerialIO implements Runnable, SerialPortEventListener { > > static CommPortIdentifier portId; > > static CommPortIdentifier saveportId; > > static Enumeration portList; > > InputStream inputStream; > > SerialPort serialPort; > > Thread readThread; > > You need a thread for your synchronous RPC-style protocol? > > > static String messageString = "Hello, world!"; > > static OutputStream outputStream; > > static boolean outputBufferEmptyFlag = false; > > > > public static void main(String[] args) { > > boolean portFound = false; > > String defaultPort; > > > > // determine the name of the serial port on several operating > systems > > String osname = System.getProperty("os.name","").toLowerCase(); > > if ( osname.startsWith("windows") ) { > > // windows > > defaultPort = "COM1"; > > } else if (osname.startsWith("linux")) { > > // linux > > defaultPort = "/dev/ttyS0"; > > } else if ( osname.startsWith("mac") ) { > > // mac > > defaultPort = "????"; > > } else { > > System.out.println("Sorry, your operating system is not > supported"); > > return; > > } > > Is such a construction recommended? Isn't there some abstraction > (like COM1 working on any platform)? > > [...] > > try { > > // activate the OUTPUT_BUFFER_EMPTY notifier > > serialPort.notifyOnOutputEmpty(true); > > } catch (Exception e) { > > System.out.println("Error setting event notification"); > > System.out.println(e.toString()); > > System.exit(-1); > > } > > I doubt that -1 is defined, probably some 127 or so would be the > result, maybe better simply `throw e'? > > > public void writetoport() { > > System.out.println("Writing \""+messageString+"\" to > "+serialPort.getName()); > > try { > > // write string to serial port > > outputStream.write(messageString.getBytes()); > > } catch (IOException e) {} > > } > > maybe something like > > /** > * Writes the given output string and an additional carriage > * return to the current outputStream. > */ > public void > writeStringToPort( > /** The output string (without CR). */ > String output > ) throws IOException > { > String outputLine = output + "\n"; > outputStream.write(outputLine.getBytes()); > } > > ? > > > > > public SerialIO() { > > // initalize serial port > > try { > > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > > } catch (PortInUseException e) {} > > if the port is in use, you continue? Wonder that this works in > Java, I would assume serialPort beeing uninitialized which AFAIK > is an error in Java. > > > try { > > inputStream = serialPort.getInputStream(); > > } catch (IOException e) {} > > > > try { > > serialPort.addEventListener(this); > > } catch (TooManyListenersException e) {} > > > > // activate the DATA_AVAILABLE notifier > > serialPort.notifyOnDataAvailable(true); > > > > try { > > // set port parameters > > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > } catch (UnsupportedCommOperationException e) {} > > > > // start the read thread > > readThread = new Thread(this); > > readThread.start(); > > > > } > > I think in all those exception cases you can abort, because it is > unlikely that ignoring those errors allow a successful > continuation, so in this case maybe it would be better to add a > throw clause to the method. > > > public void run() { > > // first thing in the thread, we initialize the write operation > > initwritetoport(); > > try { > > while (true) { > > // write string to port, the serialEvent will read it > > writetoport(); > > Thread.sleep(1000); > > } > > } catch (InterruptedException e) {} > > } > > Does this make sense? Your `SimpleReadApp' writes one and the > same string each second? > > > public void serialEvent(SerialPortEvent event) { > > switch (event.getEventType()) { > > case SerialPortEvent.BI: > > case SerialPortEvent.OE: > > case SerialPortEvent.FE: > > case SerialPortEvent.PE: > > case SerialPortEvent.CD: > > case SerialPortEvent.CTS: > > case SerialPortEvent.DSR: > > case SerialPortEvent.RI: > > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > > break; > > case SerialPortEvent.DATA_AVAILABLE: > > // we get here if data has been received > > byte[] readBuffer = new byte[20]; > > try { > > // read data > > while (inputStream.available() > 0) { > > int numBytes = inputStream.read(readBuffer); > > } > > // print data > > String result = new String(readBuffer); > > System.out.println("Read: "+result); > > } catch (IOException e) {} > > I doubt that this is correct. I would assume you will get a 20 > bytes result always, if more bytes would be available they would > be printed in a second line but if less bytes are read I'd assume > that the buffer/result contains zero bytes from implicite > readBuffer contents initialisation (zero is no string terminator > in Java AFAIK). > > > break; > > } > > } > > } > > oki, > > Steffen > > About Ingenico Throughout the world businesses rely on Ingenico for secure > and expedient electronic transaction acceptance. Ingenico products leverage > proven technology, established standards and unparalleled ergonomics to > provide optimal reliability, versatility and usability. This comprehensive > range of products is complemented by a global array of services and > partnerships, enabling businesses in a number of vertical sectors to accept > transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged > information. If you are not the addressee or authorized to receive this for > the addressee, you must not use, copy, disclose or take any action based on > this message or any information herein. If you have received this message in > error, please advise the sender immediately by reply e-mail and delete this > message. Thank you for your cooperation. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/73c4135c/attachment-0029.html From ajmas at sympatico.ca Sat Aug 16 07:15:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 09:15:41 -0400 Subject: [Rxtx] someone has seen such errors? In-Reply-To: <48A2CEFB.90007@gmx.de> References: <48A2CEFB.90007@gmx.de> Message-ID: <43B5E8DA-1D93-4D90-809B-AAF35FF724C5@sympatico.ca> On 13-Aug-08, at 08:09 , Florian Manschwetus wrote: > I mean my communication mostly works, but it is far from perfect > could this be the reason? > > Florian > > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control Judging by the error messages this looks related to the driver you are using. Do a search for the following string with you favourite search engine, it should turn up a few hits: ftdi_set_termios FAILED to set databits/stopbits/parity Andre From ajmas at sympatico.ca Sat Aug 16 19:12:04 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 21:12:04 -0400 Subject: [Rxtx] Using SerialPortEvent? Message-ID: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Hi, Could someone tell me how I should be using the SerialPortEvent? Am I meant to be waiting for data and then simply reading from the inputstream? If this is the case why no just block on an inputstream read? Andr? From tjarvi at qbang.org Sat Aug 16 19:41:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 16 Aug 2008 19:41:13 -0600 (MDT) Subject: [Rxtx] Using SerialPortEvent? In-Reply-To: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> References: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Message-ID: On Sat, 16 Aug 2008, Andre-John Mas wrote: > Hi, > > Could someone tell me how I should be using the SerialPortEvent? Am I > meant to be waiting for data and then simply reading from the > inputstream? If this is the case why no just block on an inputstream > read? > Polling for data is fine also. It really depends upon what you are trying to do. For instance, if you require x bytes before reading, you can start polling after data is available. If you read on the same thread as your GUI and are waiting for data in a read, the results may be less than desirable. Java programming is 'usually' event driven rather than polling based. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sat Aug 16 20:10:39 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 22:10:39 -0400 Subject: [Rxtx] Using SerialPortEvent? In-Reply-To: References: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Message-ID: <3E495D4C-BB28-4845-A6AB-984C9A826BDF@sympatico.ca> On 16-Aug-08, at 21:41 , Trent Jarvi wrote: > On Sat, 16 Aug 2008, Andre-John Mas wrote: > >> Hi, >> >> Could someone tell me how I should be using the SerialPortEvent? Am I >> meant to be waiting for data and then simply reading from the >> inputstream? If this is the case why no just block on an inputstream >> read? >> > > Polling for data is fine also. It really depends upon what you are > trying to do. For instance, if you require x bytes before reading, > you can start polling after data is available. If you read on the > same thread as your GUI and are waiting for data in a read, the > results may be less than desirable. > > Java programming is 'usually' event driven rather than polling based. Sounds good. I thought I would use this opportunity to provide a event based version of the TwoWaySerialComm example. Could you just validate it before I add it to the Wiki: package ajmas74.experimental; import gnu.io.CommPort; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; import gnu.io.SerialPortEvent; import gnu.io.SerialPortEventListener; import java.io.IOException; import java.io.InputStream; import java.io.OutputStream; /** * This version of the TwoWaySerialComm example makes use of the * SerialPortEventListener to avoid polling. * * @author ajmas * */ public class TwoWaySerialComm { public TwoWaySerialComm() { super(); } void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { CommPort commPort = portIdentifier.open(this.getClass().getName(),2000); if ( commPort instanceof SerialPort ) { SerialPort serialPort = (SerialPort) commPort; serialPort .setSerialPortParams (57600 ,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); (new Thread(new SerialWriter(out))).start(); serialPort.addEventListener(new SerialReader(in)); } else { System.out.println("Error: Only serial ports are handled by this example."); } } } /** * Handles the input coming from the serial port. A new line character * is treated as the end of a block in this example. */ public static class SerialReader implements SerialPortEventListener { private InputStream in; private byte[] buffer = new byte[1024]; public SerialReader ( InputStream in ) { this.in = in; } public void serialEvent(SerialPortEvent arg0) { int data; try { int len = 0; while ( ( data = in.read()) > -1 ) { if ( data != '\n' ) { break; } buffer[len++] = (byte) data; } System.out.print(new String(buffer,0,len)); } catch ( IOException e ) { e.printStackTrace(); System.exit(-1); } } } /** */ public static class SerialWriter implements Runnable { OutputStream out; public SerialWriter ( OutputStream out ) { this.out = out; } public void run () { try { int c = 0; while ( ( c = System.in.read()) > -1 ) { this.out.write(c); } } catch ( IOException e ) { e.printStackTrace(); System.exit(-1); } } } public static void main ( String[] args ) { try { (new TwoWaySerialComm()).connect("COM3"); } catch ( Exception e ) { e.printStackTrace(); } } } From lfarkas at lfarkas.org Tue Aug 19 07:32:59 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Tue, 19 Aug 2008 15:32:59 +0200 Subject: [Rxtx] JNI or CNI Message-ID: <48AACB8B.9060606@lfarkas.org> hi, what is the current recommended way to rxtx on linux JNI or it's better to use CNI? is the CNI version fully functional and the same level as the JNI? i currently try to make a rhel/centos/fedora rpm for rxtx but has many problems with the standard dir structure. yours. -- Levente "Si vis pacem para bellum!" From lfarkas at lfarkas.org Tue Aug 19 08:47:34 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Tue, 19 Aug 2008 16:47:34 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel Message-ID: <48AADD06.7040809@lfarkas.org> hi, newer or not so newer linux kernel do not contain the UTS_RELEASE so the current rxtx is not compile on the latest kernels. even if it's commented out in the cvs configure there are other places. i attcahed a patch which fix it (or at least doesn't cause error at non-debug build). ps. is there any plan to the new 2.1-8 release in the near future? there are many changes (at least the license change in all file and in this case create a diff is very difficult)? the latest release more then 2 years old:-( -- Levente "Si vis pacem para bellum!" -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-2.1-uts.patch Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080819/ab5d38ac/attachment-0023.pl From ajmas at sympatico.ca Tue Aug 19 16:21:53 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 19 Aug 2008 18:21:53 -0400 Subject: [Rxtx] Event based example Message-ID: <24735BFB-B088-4B84-8173-FE98DF63B12F@sympatico.ca> Hi, I have just posted an example of using SerialPortEventListener in the Wiki: http://rxtx.qbang.org/wiki/index.php/Event_Based_Two_Way_Communication If you see any issues please could you let me know, or makes the changes. Andre From Martin.Oberhuber at windriver.com Fri Aug 22 04:02:24 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 22 Aug 2008 12:02:24 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <48AADD06.7040809@lfarkas.org> References: <48AADD06.7040809@lfarkas.org> Message-ID: <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> Farkas, there are indeed efforts to get a new RXTX release out the door. Your experience as a package maintainer would likely be helpful during these efforts, since I'd think it makes sense to keep the patches minimal that you must make to have the source compile in your environment. What are the things that you find problematic, apart from the UTS thing that you have mentioned before? What is the timing that you have in mind for your package? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Farkas Levente > Sent: Tuesday, August 19, 2008 4:48 PM > To: rxtx at qbang.org > Subject: [Rxtx] UTS_RELEASE not defined in newer kernel > > hi, > newer or not so newer linux kernel do not contain the > UTS_RELEASE so the > current rxtx is not compile on the latest kernels. even if it's > commented out in the cvs configure there are other places. > i attcahed a patch which fix it (or at least doesn't cause error at > non-debug build). > > ps. is there any plan to the new 2.1-8 release in the near > future? there > are many changes (at least the license change in all file and in this > case create a diff is very difficult)? the latest release more then 2 > years old:-( > > -- > Levente "Si vis pacem para bellum!" > From lfarkas at lfarkas.org Fri Aug 22 04:36:26 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Fri, 22 Aug 2008 12:36:26 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> References: <48AADD06.7040809@lfarkas.org> <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> Message-ID: <48AE96AA.6090505@lfarkas.org> hi, the packages already build for fedora-9 and centos-5 and here: http://www.lfarkas.org/linux/packages/ what i've to patch, the UTS, the configure script, but it's already fixed in the cvs (in another way) and the loadlibrary. the reasons for last one can be found here: https://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_files_that_use_JNI after we test it i'd like to add these packages to fedora and epel main repository (that's why it's be useful a new release after 2 years:-) imho versions are cheap and why not just release 2.1-8? the real code changes are minimal and if something critical bug found still can release 2.1-9:-) ps. and would be better to use simple number for version like 2.1-7 rather then 2.1-7v2. Oberhuber, Martin wrote: > Farkas, > > there are indeed efforts to get a new RXTX release out the > door. Your experience as a package maintainer would likely > be helpful during these efforts, since I'd think it makes > sense to keep the patches minimal that you must make to > have the source compile in your environment. > > What are the things that you find problematic, apart from > the UTS thing that you have mentioned before? > > What is the timing that you have in mind for your package? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >> On Behalf Of Farkas Levente >> Sent: Tuesday, August 19, 2008 4:48 PM >> To: rxtx at qbang.org >> Subject: [Rxtx] UTS_RELEASE not defined in newer kernel >> >> hi, >> newer or not so newer linux kernel do not contain the >> UTS_RELEASE so the >> current rxtx is not compile on the latest kernels. even if it's >> commented out in the cvs configure there are other places. >> i attcahed a patch which fix it (or at least doesn't cause error at >> non-debug build). >> >> ps. is there any plan to the new 2.1-8 release in the near >> future? there >> are many changes (at least the license change in all file and in this >> case create a diff is very difficult)? the latest release more then 2 >> years old:-( >> >> -- >> Levente "Si vis pacem para bellum!" >> -- Levente "Si vis pacem para bellum!" From tjarvi at qbang.org Fri Aug 22 18:50:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Aug 2008 18:50:32 -0600 (MDT) Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <48AE96AA.6090505@lfarkas.org> References: <48AADD06.7040809@lfarkas.org> <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> <48AE96AA.6090505@lfarkas.org> Message-ID: Hi Farkas, The v2 was simply the second build - no code changes. We are comming out with a new release shortly. I would encourage working with distros as you are. The building of rxtx turns out to be a bottle neck in quick releases. We do want stable releases that work for a year or more but I would have no problems with quicker cycles on developing work. I would have no problem working with someone that did builds that receive less testing more often but they do have to come out for multiple platforms from this end. Thanks for the links. On Fri, 22 Aug 2008, Farkas Levente wrote: > hi, > the packages already build for fedora-9 and centos-5 and here: > http://www.lfarkas.org/linux/packages/ > what i've to patch, the UTS, the configure script, but it's already > fixed in the cvs (in another way) and the loadlibrary. the reasons for > last one can be found here: > https://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_files_that_use_JNI > after we test it i'd like to add these packages to fedora and epel main > repository (that's why it's be useful a new release after 2 years:-) > imho versions are cheap and why not just release 2.1-8? the real code > changes are minimal and if something critical bug found still can > release 2.1-9:-) > > ps. and would be better to use simple number for version like 2.1-7 > rather then 2.1-7v2. > > Oberhuber, Martin wrote: >> Farkas, >> >> there are indeed efforts to get a new RXTX release out the >> door. Your experience as a package maintainer would likely >> be helpful during these efforts, since I'd think it makes >> sense to keep the patches minimal that you must make to >> have the source compile in your environment. >> >> What are the things that you find problematic, apart from >> the UTS thing that you have mentioned before? >> >> What is the timing that you have in mind for your package? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >>> On Behalf Of Farkas Levente >>> Sent: Tuesday, August 19, 2008 4:48 PM >>> To: rxtx at qbang.org >>> Subject: [Rxtx] UTS_RELEASE not defined in newer kernel >>> >>> hi, >>> newer or not so newer linux kernel do not contain the >>> UTS_RELEASE so the >>> current rxtx is not compile on the latest kernels. even if it's >>> commented out in the cvs configure there are other places. >>> i attcahed a patch which fix it (or at least doesn't cause error at >>> non-debug build). >>> >>> ps. is there any plan to the new 2.1-8 release in the near >>> future? there >>> are many changes (at least the license change in all file and in this >>> case create a diff is very difficult)? the latest release more then 2 >>> years old:-( >>> >>> -- >>> Levente "Si vis pacem para bellum!" >>> > > > From andy at triera.net Sat Aug 23 15:17:44 2008 From: andy at triera.net (Andy Rozman) Date: Sat, 23 Aug 2008 21:17:44 +0000 Subject: [Rxtx] port not identified on FreeBSD In-Reply-To: References: Message-ID: <48B07E78.2030306@triera.net> Hi ! I have one small problem... I have started using FreeBSD in last few days and I have come accross a problem with rxtx on FreeBSD. I am using usb-to-serial converter, which is identified under FreeBSD without problem as ucom0, and creates link under /dev called ttyU0, which is correct way to be done under FreeBSD (if device would be unidentified it would be called ugen0 - as usb generic). Problem is that I say to rxtx to get my all serial ports this one is not among them. Which names are permissable under linux-like implementations? Which will be accepted as serial ports? Andy From tjarvi at qbang.org Sat Aug 23 13:57:45 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 23 Aug 2008 13:57:45 -0600 (MDT) Subject: [Rxtx] port not identified on FreeBSD In-Reply-To: <48B07E78.2030306@triera.net> References: <48B07E78.2030306@triera.net> Message-ID: On Sat, 23 Aug 2008, Andy Rozman wrote: > Hi ! > > I have one small problem... I have started using FreeBSD in last few > days and I have come accross a problem with rxtx on FreeBSD. > > I am using usb-to-serial converter, which is identified under FreeBSD > without problem as ucom0, and creates link under /dev called > ttyU0, which is correct way to be done under FreeBSD (if device would be > unidentified it would be called ugen0 - as usb generic). Problem is that > I say to rxtx to get my all serial ports this one is not among them. > Which names are permissable under linux-like implementations? Which will > be accepted as serial ports? > > Andy > Thanks Andy! We will add ttyU* to FreeBSD. For now you can use properties to enable the port. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting#How_does_rxtx_detect_ports.3F__Can_I_override_it.3F The fix: diff -u -r1.16.2.59 RXTXCommDriver.java --- RXTXCommDriver.java 18 Nov 2007 22:32:41 -0000 1.16.2.59 +++ RXTXCommDriver.java 23 Aug 2008 19:55:25 -0000 @@ -644,6 +644,7 @@ { String[] Temp = { "ttyd", //general purpose serial ports + "ttyU", //general purpose USB serial ports "cuaa", //dialout serial ports "ttyA", //Specialix SI/XIO dialin ports "cuaA", //Specialix SI/XIO dialout ports -- Trent Jarvi tjarvi at qbang.org From rick_knight at rlknight.com Mon Aug 4 13:25:10 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Mon, 04 Aug 2008 12:25:10 -0700 Subject: [Rxtx] Sun's Comm API? Message-ID: <48975796.4010600@rlknight.com> I have an application that requires the javax compatible version of RXTX and Sun's comm api. I've been able to download and extract the version of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api anywhere. Can someone tell me where I can find it? Or maybe send me a copy? Also, when I try to build RXTX, configure and make complete successfully but make install failes with this error libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 I've never come accross this error before. How can I get past it? Thanks, Rick From bboyes at systronix.com Mon Aug 4 19:10:01 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:10:01 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48975796.4010600@rlknight.com> References: <48975796.4010600@rlknight.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/cb9c6167/attachment-0039.html From bboyes at systronix.com Mon Aug 4 19:12:37 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:12:37 -0600 Subject: [Rxtx] Towards an RXTX release - CSR BT/USB chipset In-Reply-To: <488FB7E7.8000802@gmail.com> References: <460801A4097E3D4CA04CC64EE648584806C56CF0@ism-mail03.corp.ad.wrs.com> <13557-75390@sneakemail.com> <20980-23424@sneakemail.com> <488FB7E7.8000802@gmail.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/52236088/attachment-0039.html From tjarvi at qbang.org Mon Aug 4 19:42:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 19:42:21 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: On Mon, 4 Aug 2008, Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: > I have an application that requires the javax compatible > version of RXTX > and Sun's comm api. I've been able to download and extract > the version > of RXTX that I need (2.0-7pre2) but I can't find Sun's camm > api > anywhere. Can someone tell me where I can find it? Or maybe > send me a > > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm port > support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have just > a ZIP with only the .class JAR file - no source or docs), has a readme > with these comments: > > This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release.? The 2.0.3 release itself is > no longer distributed.? comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project.? The RxTx project (http://www.rxtx.org ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org) was opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support.? Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins.? Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > ? > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > I hope that is helpful! > It would be nice to work with Sun to resolve those longstanding issues. But it may not be practical unless the process goes as fast and painless as the grandfathering of commapi did. Another option may be the old kaffe extensions that moved to gnu classpathx. These don't have the native libraries but should provide the 2.0 interface and the javax.comm.properties mechansim for SPI. http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Mon Aug 4 20:23:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Mon, 04 Aug 2008 20:23:57 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4897B9BD.5070809@ergotech.com> Has there been any work/would it be possible, to layer a javacomm look-alike on top of the GNU code? The goal is not to move the javax code forward, but to emulate the "legacy" javax packages for people who still need this. Jim Trent Jarvi wrote: > On Mon, 4 Aug 2008, Bruce Boyes wrote: > >> At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible >> version of RXTX >> and Sun's comm api. I've been able to download and extract >> the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm >> api >> anywhere. Can someone tell me where I can find it? Or maybe >> send me a >> >> >> javaxcomm has had a sort of on-again off-again history. The windoze >> version has been languishing for years (literally) but there are newer >> versions for other OS's. >> >> We try to keep links on one of our help pages current: >> http://www.practicalembeddedjava.com/tools/javatools_list.html >> which gets you to here: >> http://java.sun.com/products/javacomm/ >> where it says in fact they no longer even support Windows and Mac: >> "Implementations of the API are currently available for Solaris SPARC, >> Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so >> someone could support it. But I guess that's part of the reason RXTX >> exists! >> >> So one of Sun's own products, SunSPOT, has to use RXTX to get comm port >> support. >> >> The version we use is 2.0 from 11/15/1998. I have posted it on our >> website, which is within the terms of the license agreement contained >> therein (as I understand it). >> >> The last version of javaxcomm for Windows, 2.0.3, (for which I have just >> a ZIP with only the .class JAR file - no source or docs), has a readme >> with these comments: >> >> This distribution contains the comm.jar file original part >> of the COMMAPI 2.0.3 release. The 2.0.3 release itself is >> no longer distributed. comm.jar, which contains the comm >> API java class files (eg. Sun's binary implementation of the >> interface classes), is being made available, unsupported, >> with no obligation to fix bugs, at the request of the RXTX >> project. The RxTx project (http://www.rxtx.org ), uses the >> comm.jar class files, but provides their own native library >> components to provide support for other platforms. >> >> The 2.0.3 comm.jar is being provided in this way because >> as of COMMAPI 3.x, the java binary implementation forked and >> became incompatible with the RxTx project's native code. >> Due to the lack of a clear business case, and to resource >> constraints, no additional resources are being >> provided to provide an alternative engineering solution >> at the time of writing. >> >> RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: >> >> Ultimately the COMMAPI would be better served if a Java >> Community Process JSR (http://www.jcp.org) was opened and >> the COMMAPI was rearchitected to provide a more pluggable >> framework to improve cross-platform support. Such an >> architecture would embody a better defined and better >> documented SPI interface, including a way for comm. ports >> to be revealed to the client application through the API >> via platform-aware plugins. Similarly, native code used >> to access comm port in general could be handled more >> flexibly using a plugin model, whereby on any platform, >> multiple native modules could be in use simultaneously. >> >> Since there are now various ways serial ports can be implemented >> and accessed, modular comm. port JNI native libraries would be >> of benefit insofar as removing the burden of over-generalization >> from any single native component, or inversely, by relieving the >> implicit constraint that comm. drivers be accessed only via a >> monolithic mechanism, such as the UNIX vnode interface. >> >> paul.klissner at sun.com >> 6/10/06 >> >> I hope that is helpful! >> > > It would be nice to work with Sun to resolve those longstanding issues. > But it may not be practical unless the process goes as fast and painless > as the grandfathering of commapi did. > > Another option may be the old kaffe extensions that moved to gnu > classpathx. These don't have the native libraries but should provide > the 2.0 interface and the javax.comm.properties mechansim for SPI. > > http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Mon Aug 4 21:09:15 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 21:09:15 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? Message-ID: Hi Jim, I will not step into the javax.comm namespace without Sun's explicite permission. I fully understand the pain point you are trying to address. In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm Linux) - which remains an integral part of rxtx. At the time it was a win for Sun and rxtx. The Sun commapi license is/was fairly clear that rxtx should not step into that namespace. It made sense as Sun was active in that space and rxtx may go into another namespace - it was an experiment in working with Sun. This may sound silly looking at something that happened almost 10 years ago. In a community of respect which Sun helped create, there is no question about what to do. I hope eventually Sun will step up and do a right thing too. I agree that this is hurting the API more than helping it. There are also questions about how to replace the API in the long term which includes HID support which isn't going well so far. Others that can't even look at Sun's javax.comm today and can look at Kaffe's contribution to classpathx can easily work around such restrictions. On Mon, 4 Aug 2008, Jim Redman wrote: > Has there been any work/would it be possible, to layer a javacomm > look-alike on top of the GNU code? > > The goal is not to move the javax code forward, but to emulate the > "legacy" javax packages for people who still need this. > > Jim > > Trent Jarvi wrote: >> >> It would be nice to work with Sun to resolve those longstanding issues. >> But it may not be practical unless the process goes as fast and painless >> as the grandfathering of commapi did. >> >> Another option may be the old kaffe extensions that moved to gnu >> classpathx. These don't have the native libraries but should provide >> the 2.0 interface and the javax.comm.properties mechansim for SPI. >> >> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From florianmanschwetus at gmx.de Tue Aug 5 05:04:46 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 13:04:46 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: References: <48971C1F.9020806@gmx.de> Message-ID: <489833CE.1040801@gmx.de> Just look at sendCommand in this method I have to place a Thread.sleep(20) after each byte send to get working. Even the event based receive doesn't work fine but this could be may stupidness. The specifikation document (it is on the last pages of the manual) for the beamer could be found on: http://www.optoma.co.uk/support.aspx Florian Manschwetus Trent Jarvi schrieb: > > Hi Florian > > Sorry for the top post in advance. I worry you may not see my answer > under all your code :) > > I have not received this email before. This is 500k of code which I > don't have time to read. I can spend about 5 min on each hobby email > and still get to work in the morning. I have a couple suggestions for > how to get an answer. > > First, cut out your comments and extra code so you can demonstrate the > question (I might even glance and see what is wrong then). Don't go for > a working final product. Isolate the problem using a simple program and > then ask with that as an example. If I did what you just did, I'd have > to post 3/4 of a million lines of code :) > > Second, join the rxtx mail-list and ask there. This will give you 100x > more eyes. I'll also read and try to follow. > > -- > taj > > > > On Mon, 4 Aug 2008, Florian Manschwetus wrote: > >> It could be that my university account is blocked by filters so >> resending from here. >> >> >> Topic is to control Optoma HD80 beamer using rs232 serial chat. >> This code is able to detect power state and switch the beamer on / off. >> connected is the beamer using a digitus usb 2.0 serial adapter with an >> FT232 USB-Serial adapter the systems architecture is amd64. >> >> Please take a look in the sendCommand routine i have to place theire >> those Thread.sleep to get it working. >> Now the question is this correct or is there a better way to get this >> working correctly? >> >> In the javadoc coming with the install i found this: >> setBaudBase >> >> public boolean setBaudBase(int BaudBase) >> throws UnsupportedCommOperationException, >> java.io.IOException >> >> Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 >> before using. >> >> could this explain the error? >> I attached my java source and the protocol description for the beamer >> (available on vendor website). >> >> thx, >> Florian Manschwetus >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: TestRS232.java Type: text/x-java Size: 9143 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0078.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0079.bin From michael.erskine at ketech.com Tue Aug 5 05:53:49 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Tue, 5 Aug 2008 12:53:49 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489833CE.1040801@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> > Just look at sendCommand in this method I have to place a > Thread.sleep(20) after each byte send to get working. Even the event > based receive doesn't work fine but this could be may stupidness. Hi Florian, Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. Regards, Michael Erskine. From florianmanschwetus at gmx.de Tue Aug 5 07:28:15 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:28:15 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> Message-ID: <4898556F.8000208@gmx.de> Michael Erskine schrieb: >> Just look at sendCommand in this method I have to place a >> Thread.sleep(20) after each byte send to get working. Even the event >> based receive doesn't work fine but this could be may stupidness. > > Hi Florian, > > Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. > > Regards, > Michael Erskine. > Ok, sounds fine for the receiving problem. But why i have to wait after each byte when sending a command squence? (the for loop in send command) Florian > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/284f350c/attachment-0038.bin From florianmanschwetus at gmx.de Tue Aug 5 07:44:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:44:14 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <4898592E.2020908@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >>> Just look at sendCommand in this method I have to place a >>> Thread.sleep(20) after each byte send to get working. Even the event >>> based receive doesn't work fine but this could be may stupidness. >> >> Hi Florian, >> >> Yes, naturally you'll have to wait for a response from the other end. >> Why not wait for notification from the event thread perhaps using a >> BlockingDeque rather than your LinkedList. Generally I >> try to decouple all input and output streams: in your case your >> application is operating synchronously like the "expect" program >> (http://expect.nist.gov/) so waits (or timeouts) will need to be >> factored in. >> >> Regards, >> Michael Erskine. >> > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) > > Florian Furthermore there is this basic baud with this confusing javadoc entry: public boolean setBaudBase(int BaudBase) throws UnsupportedCommOperationException, java.io.IOException Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 before using. maybe this could explain something Florian >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/006c7425/attachment-0038.bin From jredman at ergotech.com Tue Aug 5 09:13:36 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 05 Aug 2008 09:13:36 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: Message-ID: <48986E20.3060104@ergotech.com> Trent, So two issues: 1) Technically I'm still not sure how easy/practical a layer would be. The problems are always classes like listeners, and wrapping returns of gnu.io classes. I really see it as a "delegate" type of concept. Any thoughts or ideas of the practicality of this approach? The idea is not to modify RXTX. 2) Javax. The javax namespace does seem to be in widespread use outside of Sun (the same is true for the java namespace). The classpath extensions, or some other location, should be interested in a JavaComm implementation even if it does have dependencies on RXTX. Would you have any philosophical objection to an approach like that? Of course, I suspect it might be better if someone with that authority at Sun would admit that the javax namespace is already in the wild and that there is no problem with it being used within RXTX. Jim Trent Jarvi wrote: > Hi Jim, > > I will not step into the javax.comm namespace without Sun's explicite > permission. I fully understand the pain point you are trying to address. > > In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm > Linux) - which remains an integral part of rxtx. At the time it was a win for > Sun and rxtx. > > The Sun commapi license is/was fairly clear that rxtx should not step into that > namespace. It made sense as Sun was active in that space and rxtx may go into > another namespace - it was an experiment in working with Sun. > > This may sound silly looking at something that happened almost 10 years ago. > In a community of respect which Sun helped create, there is no question about > what to do. I hope eventually Sun will step up and do a right thing too. > > I agree that this is hurting the API more than helping it. There are also > questions about how to replace the API in the long term which includes HID > support which isn't going well so far. > > Others that can't even look at Sun's javax.comm today and can look at Kaffe's > contribution to classpathx can easily work around such restrictions. > > On Mon, 4 Aug 2008, Jim Redman wrote: > >> Has there been any work/would it be possible, to layer a javacomm >> look-alike on top of the GNU code? >> >> The goal is not to move the javax code forward, but to emulate the >> "legacy" javax packages for people who still need this. >> >> Jim >> >> Trent Jarvi wrote: >>> It would be nice to work with Sun to resolve those longstanding issues. >>> But it may not be practical unless the process goes as fast and painless >>> as the grandfathering of commapi did. >>> >>> Another option may be the old kaffe extensions that moved to gnu >>> classpathx. These don't have the native libraries but should provide >>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>> >>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From sandeep at genevasoftech.com Tue Aug 5 11:18:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Tue, 05 Aug 2008 22:48:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <48988B6C.5080409@genevasoftech.com> Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. *-- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/ad20f1cb/attachment-0038.html From Martin.Oberhuber at windriver.com Tue Aug 5 13:30:17 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Tue, 5 Aug 2008 21:30:17 +0200 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Sandeep, shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on Sol7 but I've successfully run it on Sol9 and Sol10. Or is your request really about a native 64bit variant? I'm afraid that then you're out of luck since I think that quite a bit of RXTX is not yet ready for 64 bit. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Sandeep Kumar K Sent: Tuesday, August 05, 2008 7:19 PM To: rxtx at qbang.org Subject: [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so for Solaris 9 Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. -- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/81b7f988/attachment-0038.html From tjarvi at qbang.org Tue Aug 5 22:38:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 22:38:34 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 5 Aug 2008, Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built > on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid that > then > you're out of luck since I think that quite a bit of RXTX is not yet > ready > for 64 bit. > While rxtx-2.1-7 probably has problems, The CVS code should be OK for 64 bit Solaris. If it isn't, let me know and I'll find which patch is missing. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Aug 5 23:13:00 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 23:13:00 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48986E20.3060104@ergotech.com> References: <48986E20.3060104@ergotech.com> Message-ID: On Tue, 5 Aug 2008, Jim Redman wrote: > Trent, > > So two issues: > > 1) Technically I'm still not sure how easy/practical a layer would be. The > problems are always classes like listeners, and wrapping returns of gnu.io > classes. I really see it as a "delegate" type of concept. Any thoughts or > ideas of the practicality of this approach? The idea is not to modify RXTX. I have not put too much thought into this. I assume you want what rxtx 2.0 provided to tie into javax.comm implementations. More classes could be added to rxtx 2.1-7 for SPI support. Maintaining rxtx-2.0 could also be handed to someone if they like. > > 2) Javax. The javax namespace does seem to be in widespread use outside of > Sun (the same is true for the java namespace). The classpath extensions, or > some other location, should be interested in a JavaComm implementation even > if it does have dependencies on RXTX. Would you have any philosophical > objection to an approach like that? > No problems. Classpathx would be a possible place to do it. I'd suggest thinking twice about what this involves in practical terms. You would be wanting to revive the 2.0 API while Sun is at 3.0 and grandfathering the JSR. This undermines the main reason (established api) for using the javax.comm namespace and does not leave such a project in a good position. The only win I see here is maintaining support for applications that can't migrate namespaces. Not that that isn't important. At some point it is going to be less work to just edit the bytecode :) Such a javax.comm effort would also be signing up new projects that decided to use the work up for concerns they probably will not understand or expect. That probably isn't a good path to facilitate for new projects at this time. We will put a good faith effort to work well with others but keep in mind the project has limited bandwidth for such efforts. > Of course, I suspect it might be better if someone with that authority at Sun > would admit that the javax namespace is already in the wild and that there is > no problem with it being used within RXTX. > > Jim > > Trent Jarvi wrote: >> Hi Jim, >> >> I will not step into the javax.comm namespace without Sun's explicite >> permission. I fully understand the pain point you are trying to address. >> >> In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java >> Comm Linux) - which remains an integral part of rxtx. At the time it was a >> win for Sun and rxtx. >> >> The Sun commapi license is/was fairly clear that rxtx should not step into >> that namespace. It made sense as Sun was active in that space and rxtx may >> go into another namespace - it was an experiment in working with Sun. >> >> This may sound silly looking at something that happened almost 10 years >> ago. In a community of respect which Sun helped create, there is no >> question about what to do. I hope eventually Sun will step up and do a >> right thing too. >> >> I agree that this is hurting the API more than helping it. There are also >> questions about how to replace the API in the long term which includes HID >> support which isn't going well so far. >> >> Others that can't even look at Sun's javax.comm today and can look at >> Kaffe's contribution to classpathx can easily work around such >> restrictions. >> >> On Mon, 4 Aug 2008, Jim Redman wrote: >> >>> Has there been any work/would it be possible, to layer a javacomm >>> look-alike on top of the GNU code? >>> >>> The goal is not to move the javax code forward, but to emulate the >>> "legacy" javax packages for people who still need this. >>> >>> Jim >>> >>> Trent Jarvi wrote: >>>> It would be nice to work with Sun to resolve those longstanding issues. >>>> But it may not be practical unless the process goes as fast and painless >>>> as the grandfathering of commapi did. >>>> >>>> Another option may be the old kaffe extensions that moved to gnu >>>> classpathx. These don't have the native libraries but should provide >>>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>>> >>>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From sandeep at genevasoftech.com Wed Aug 6 00:03:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Wed, 06 Aug 2008 11:33:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: <48993EB8.30107@genevasoftech.com> Thank you Mr. Martin for your suggestion. The native file which is given in rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am getting the following error . Any suggestions to solve this issue. I am using Solaris SPARC 64 bit machine. ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) thrown while loading gnu.io.RXTXCommDriver Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(Unknown Source) at java.lang.ClassLoader.loadLibrary(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) at com.ReadFromModem.main(ReadFromModem.java:84) * * *Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid > that then > you're out of luck since I think that quite a bit of RXTX is not yet ready > for 64 bit. > > Cheers, > -- > *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > ------------------------------------------------------------------------ > *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On > Behalf Of *Sandeep Kumar K > *Sent:* Tuesday, August 05, 2008 7:19 PM > *To:* rxtx at qbang.org > *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so > for Solaris 9 > > Hi, > > Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 > bit machine. The librxtxSerial.so given in website is for Solaris 8. > > *-- > > Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/1e920343/attachment-0038.html From tjarvi at qbang.org Wed Aug 6 00:21:42 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 00:21:42 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <48993EB8.30107@genevasoftech.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> <48993EB8.30107@genevasoftech.com> Message-ID: Hi Sandeep You may be out of luck unless you can compile the 2.1 src in CVS (requires gnu make and gcc). But you could try the ToyBox(R)(TM) which is a collection of WiLdLy untested cross compiled 2.1-7 binaries covering everything from the ibm z series to embeded arm/ppc. To give an idea how poorly these are tested, I don't even know if z series machines have a serial port. ftp://www.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Solaris They should at least match the binary types. Actually, I think if you use the rxtx jar from CVS with that file, it should 'work' as the fix for 64 bits was in java not the native code. You could just cd rxtx*/src; javac *.java then jar -cf RXTXcomm.jar `find -name \*.class` to create the hybrid which will complain about version information a bit. On Wed, 6 Aug 2008, Sandeep Kumar K wrote: > Thank you Mr. Martin for your suggestion. The native file which is given in > rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am > getting the following error . > Any suggestions to solve this issue. > I am using Solaris SPARC 64 bit machine. > > ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar > java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 > (Possible cause: architecture word > width mismatch) thrown while loading gnu.io.RXTXCommDriver > Exception in thread "main" java.lang.UnsatisfiedLinkError: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF > class: ELFCLASS64 (Possible cause: > architecture word width mismatch) > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(Unknown Source) > at java.lang.ClassLoader.loadLibrary(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > at com.ReadFromModem.main(ReadFromModem.java:84) > > * > * > > *Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > > > Oberhuber, Martin wrote: >> Sandeep, >> shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse >> variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on >> Sol7 but I've successfully run it on Sol9 and Sol10. >> Or is your request really about a native 64bit variant? I'm afraid that >> then >> you're out of luck since I think that quite a bit of RXTX is not yet ready >> for 64 bit. >> Cheers, >> -- >> *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> ------------------------------------------------------------------------ >> *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On >> Behalf Of *Sandeep Kumar K >> *Sent:* Tuesday, August 05, 2008 7:19 PM >> *To:* rxtx at qbang.org >> *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so >> for Solaris 9 >> >> Hi, >> >> Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 >> bit machine. The librxtxSerial.so given in website is for Solaris 8. >> >> *-- >> Thanks & Regards >> >> Sandeep Kumar K >> Sr. Software Engineer >> Geneva Software Technologies >> Whitefield, Bangalore >> Mob : 9880193454* >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> From michael.erskine at ketech.com Wed Aug 6 01:39:28 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 6 Aug 2008 08:39:28 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Florian Manschwetus wrote: > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) Hi Florian, I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. Regards, Michael Erskine. From florianmanschwetus at gmx.de Wed Aug 6 02:53:16 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 06 Aug 2008 10:53:16 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Message-ID: <4899667C.6010706@gmx.de> Michael Erskine schrieb: > Florian Manschwetus wrote: >> Ok, sounds fine for the receiving problem. >> But why i have to wait after each byte when sending a command squence? >> (the for loop in send command) > > Hi Florian, > I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. > > Regards, > Michael Erskine. > correct with a terminal on the other end it works, my idea was that this basic baud has some influence. Could some one explain what it is for? Florian > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/c2b4fa84/attachment-0038.bin From rick_knight at rlknight.com Wed Aug 6 13:01:07 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:01:07 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F4F3.3020707@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > I have an application (Readerware) that uses RXTX with Javax to access the serial port. This used to work fine under previous Linux' and Java, but something has changed, I assume with Java itself , that is causing the application to fail with a link error. The application is not able to find librxtxSerialParallel.so. RXTX supplies librxtxSerial.so and librxtxParallel.so, but not librxtxSerialParallel.so. Where can I get librxtxSerialParallel.so, or do I need it? Is something else causing the lib to not be found? Thanks, Rick Knight From rick_knight at rlknight.com Wed Aug 6 13:17:55 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:17:55 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F8E3.5060400@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Thanks for the reply. The developer of the app I'm trying to use (Readerware) has sent me a copy of the comm.api and I've copied the library (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar into the proper places. When I try to run the application, I get this error... Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: /usr/lib/libSolarisSerialParallel.so: /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not little-endian (Possible cause: endianness mismatch) Caught java.lang.UnsatisfiedLinkError: com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I while loading driver com.sun.comm.SolarisDriver Is there a way around this error? Thanks again, Rick Knight From jlar310 at gmail.com Wed Aug 6 13:37:42 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 14:37:42 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899F8E3.5060400@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > The developer of the app I'm trying to use (Readerware) has sent me a > copy of the comm.api and I've copied the library > (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar > into the proper places. When I try to run the application, I get this > error... > > Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: > /usr/lib/libSolarisSerialParallel.so: > /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not > little-endian (Possible cause: endianness mismatch) > Caught java.lang.UnsatisfiedLinkError: > com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I > > while loading driver com.sun.comm.SolarisDriver > > Is there a way around this error? What host OS are you running? From your original post it looks like 32 bit Linux. The libSolarisSerialParallel.so file is for Sun Solaris and will vary depending on the underlying hardware architecture as well. Sorry for the double post Rick, but I failed to send this to the list the first time... -- Jeff From rick_knight at rlknight.com Wed Aug 6 13:44:29 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:44:29 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: <4899FF1D.9030504@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > > >> The developer of the app I'm trying to use (Readerware) has sent me a >> copy of the comm.api and I've copied the library >> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >> into the proper places. When I try to run the application, I get this >> error... >> >> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >> /usr/lib/libSolarisSerialParallel.so: >> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >> little-endian (Possible cause: endianness mismatch) >> Caught java.lang.UnsatisfiedLinkError: >> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >> >> while loading driver com.sun.comm.SolarisDriver >> >> Is there a way around this error? >> > > What host OS are you running? From your original post it looks like 32 > bit Linux. > > The libSolarisSerialParallel.so file is for Sun Solaris and will vary > depending on the underlying hardware architecture as well. > > I'm running Kubuntu Linux (debian based). It's 32 bit. Rick Knight From jlar310 at gmail.com Wed Aug 6 15:33:23 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 16:33:23 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > I don't think Sun did binary libraries for Linux in the 2.0 version. Can someone with more historical experience than I confirm that? I recently tried to port a Comm API application from Solaris sparc to Linux x86 and likewise could not get my hands on the binary libraries. I eventually just re-wrote the code to use the gnu namespace packages and rxtx 2.1. What I don't understand is why your application vendor does not provide everything you need to run their software. FYI: I have librxtxParallel.so and librxtxSerial.so installed at JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is /usr/java/default which is actually a softlink to /usr/java/jre1.6.0_05. -- Jeff From defiantlew at yahoo.com.au Wed Aug 6 16:29:33 2008 From: defiantlew at yahoo.com.au (Lew L) Date: Thu, 7 Aug 2008 08:29:33 +1000 Subject: [Rxtx] Sun's Comm API Documentation References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> Message-ID: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> As a matter of interest is the Sun Comm API documentation available somewhere? I have tried the Sun site but it seems to have been removed. Unless I have missed the documentation for RXTX? I javadocced the RXTX source but information (to me) is minimal. Somewhere I got the impression that the Sun Comm API docs is, or was, compatible with RXTX, what is the best docs to use in conjuntion with RXTX and where may the be available? Cheers Lew From rick_knight at rlknight.com Wed Aug 6 17:18:33 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:18:33 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A3149.4050306@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff I'm not sure if I posted this here or not, but when I try to build RXTX from source I get this install error... make all-am make[1]: Entering directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' make[1]: Nothing to be done for `all-am'. make[1]: Leaving directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 Can you tell me how to get past this error and get RXTX built and installed? Thanks, Rick From bboyes at systronix.com Wed Aug 6 17:40:12 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Wed, 06 Aug 2008 17:40:12 -0600 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: At 16:29 08/06/2008, Lew L wrote: >As a matter of interest is the Sun Comm API documentation available >somewhere? I have tried the Sun site but it seems to have been removed. It's in the file we have posted, link in prev email (sorry, in a huge hurry right now). Javadocs definitely there. >Unless I have missed the documentation for RXTX? I javadocced the RXTX >source but information (to me) is minimal. >Somewhere I got the impression that the Sun Comm API docs is, or was, >compatible with RXTX, what is the best docs to use in conjuntion with RXTX >and where may the be available? Yeah, this is one of my concerns/beefs. There is little documentation for RXTX and it isn't just the same as javaxcomm. I would be willing to help out writing docs for RXTX! Yes really... esp if we can fix the Bluetooth issues. best regards Bruce >Cheers >Lew > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx ------- WWW.SYSTRONIX.COM ---------- Real embedded Java and much more +1-801-534-1017 Salt Lake City, USA From rick_knight at rlknight.com Wed Aug 6 17:54:08 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:54:08 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A39A0.2090309@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff, I would like for my vendor to switch to rxtx 2.1. It would make things much easier for me. I'm not sure why he's still using the javax compatible code. He's a small operation. Re-writing the code to use gnu namespace sounds like a major overhaul. Was it? Thanks, Rick From tjarvi at qbang.org Wed Aug 6 21:35:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:35:12 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: >> >>> Jeff wrote: >>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>>> >>>> >>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things > much easier for me. I'm not sure why he's still using the javax > compatible code. He's a small operation. Re-writing the code to use gnu > namespace sounds like a major overhaul. Was it? > Hi Jeff, The changes are fairly mechanical. Imports need to change and any explicite use of the namespace needs to change such as catching an exception. The following script was made for maintaining rxtx 2.0 but can apply to other needs. It is in the contrib dir with rxtx source. #!/bin/sh # Don't use! :) # # Sat, 03 May 2003 16:45:08 Modifications from J?rg Weule # Create a ed-cmd for the change of one pattern # case $1 in gnu) X=g/javax_comm/s+javax_comm+gnu_io+g ;; javax) X=g/gnu_io/s+gnu_io+javax_comm+g ;; *) echo;echo;echo From the top rxtx directory run;echo;echo -e \\t./ChangePackage.sh gnu;echo -e \\t\\tor;echo -e \\t./ChangePackage.sh javax;echo;echo; exit 0 ;; esac # # ed will be used to keep the owner and mode of the files unchanged. # We have run the ed-script for the characters '.' '/' as well. # "tr _ $D" do the change. # find . -type f -a -print | grep -v $0 | (while read F ; do ( echo $X; echo $X| tr _ /; echo $X| tr _ .; echo w; echo q ) | ed $F 2>&1 >/dev/null done ) # # Now we do little changes at the Makefiles. Hope that all we need. # find . -name Makefile\* -a -print | (while read F ; do cat < References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: On Thu, 7 Aug 2008, Lew L wrote: > As a matter of interest is the Sun Comm API documentation available > somewhere? I have tried the Sun site but it seems to have been removed. > > Unless I have missed the documentation for RXTX? I javadocced the RXTX > source but information (to me) is minimal. > Somewhere I got the impression that the Sun Comm API docs is, or was, > compatible with RXTX, what is the best docs to use in conjuntion with RXTX > and where may the be available? > Hi Lew, The documentation on Sun's website is accurate. The changes that are problematic in 3.0 are on the backside which rxtx used to plug into. http://java.sun.com/products/javacomm/reference/api/index.html CommPortIdentifier may have some minor differences (judging by the authors notes). -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Aug 6 21:46:08 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:46:08 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > If javax.comm.properties is properly installed and you are using a 2.0 version of Sun's commapi with rxtx 2.0, you should not see the library attempt to load libSolarisSerialParallel.so. Sun CommAPI 3.0 will not work with any version of rxtx as it is hard coded to use the shared library. See the INSTALL file with rxtx-2.0 source for more help with the properties file. -- Trent Jarvi tjarvi at qbang.org From jlar310 at gmail.com Thu Aug 7 06:32:06 2008 From: jlar310 at gmail.com (Jeff) Date: Thu, 7 Aug 2008 07:32:06 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > Jeff wrote: >> >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >> wrote: >> >>> >>> Jeff wrote: >>> >>>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>> wrote: >>>> >>>> >>>> >>>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things much > easier for me. I'm not sure why he's still using the javax compatible code. > He's a small operation. Re-writing the code to use gnu namespace sounds like > a major overhaul. Was it? I found it quite easy. In fact, in order to accommodate the transition, I actually separated all of the code that deals directly with the Comm API or RXTX into a helper class. The helper class was then coded to use reflection to determine which library was available and then instantiate the necessary objects. No direct imports of either library are used. The main application just needs to get it's hands on the IO streams and need not deal directly with the libraries. Other programs may not be so simple... But this doesn't really help you unless your vendor forks over the source code... -- Jeff From rick_knight at rlknight.com Thu Aug 7 09:47:12 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Thu, 07 Aug 2008 08:47:12 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: <489B1900.10108@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >>> wrote: >>> >>> >>>> Jeff wrote: >>>> >>>> >>>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>>> copy of the comm.api and I've copied the library >>>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>>> into the proper places. When I try to run the application, I get this >>>>>> error... >>>>>> >>>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>>> /usr/lib/libSolarisSerialParallel.so: >>>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>>> little-endian (Possible cause: endianness mismatch) >>>>>> Caught java.lang.UnsatisfiedLinkError: >>>>>> >>>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>>> >>>>>> while loading driver com.sun.comm.SolarisDriver >>>>>> >>>>>> Is there a way around this error? >>>>>> >>>>>> >>>>>> >>>>> What host OS are you running? From your original post it looks like 32 >>>>> bit Linux. >>>>> >>>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>>> depending on the underlying hardware architecture as well. >>>>> >>>>> >>>>> >>>>> >>>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>>> >>>> >>>> >>> I don't think Sun did binary libraries for Linux in the 2.0 version. >>> Can someone with more historical experience than I confirm that? >>> >>> I recently tried to port a Comm API application from Solaris sparc to >>> Linux x86 and likewise could not get my hands on the binary libraries. >>> I eventually just re-wrote the code to use the gnu namespace packages >>> and rxtx 2.1. >>> >>> What I don't understand is why your application vendor does not >>> provide everything you need to run their software. >>> >>> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >>> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >>> /usr/java/default which is actually a softlink to >>> /usr/java/jre1.6.0_05. >>> >>> >>> >> Jeff, >> >> I would like for my vendor to switch to rxtx 2.1. It would make things much >> easier for me. I'm not sure why he's still using the javax compatible code. >> He's a small operation. Re-writing the code to use gnu namespace sounds like >> a major overhaul. Was it? >> > > I found it quite easy. In fact, in order to accommodate the > transition, I actually separated all of the code that deals directly > with the Comm API or RXTX into a helper class. The helper class was > then coded to use reflection to determine which library was available > and then instantiate the necessary objects. No direct imports of > either library are used. The main application just needs to get it's > hands on the IO streams and need not deal directly with the libraries. > Other programs may not be so simple... > > But this doesn't really help you unless your vendor forks over the > source code... > > Jeff, This may not help me directly, but I'm going to forward this thread to the vendor. I think he'll be open to making things work. Thanks again, Rick Knight From agusmunioz at gmail.com Thu Aug 7 16:39:51 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Thu, 7 Aug 2008 19:39:51 -0300 Subject: [Rxtx] How to send ack? Message-ID: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Hi, I'm still learning about serial communication and I have some doubts. I've got this question about how to do the following thing in rxtx. I have this hardware that connect to a PC using a serial port. These hardware receives data from a telephone line, proccess it, and then send it forward to the serial port. I've used a program named wincomm that shows what information is send it through the serial port and I have the nex behaviour: The hardware has a buffer where all data is stored, that cannot be sent it through the seria port. The program reads the first data send it by the hardware, and keep reading the same data always. There is a button in the application that says enable Ack, and when I click, then the hardware start to send all the stored information, and all the information is shown. I write a class, using rxtx that reads the serial port, and the same thing happens, it remains reading the same (first) data all the time. And I thing something like the enable Ack I'm missing. How can I do this enable Ack from my java code using rxtx? Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080807/e0a0f9a1/attachment-0036.html From ajmas at sympatico.ca Thu Aug 7 18:26:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 7 Aug 2008 20:26:41 -0400 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: <4BF42297-81E2-4BB8-A89F-1D43588379AE@sympatico.ca> On 6-Aug-08, at 19:40 , Bruce Boyes wrote: >> Unless I have missed the documentation for RXTX? I javadocced the >> RXTX >> source but information (to me) is minimal. >> Somewhere I got the impression that the Sun Comm API docs is, or was, >> compatible with RXTX, what is the best docs to use in conjuntion >> with RXTX >> and where may the be available? > > Yeah, this is one of my concerns/beefs. There is little documentation > for RXTX and it isn't just the same as javaxcomm. > > I would be willing to help out writing docs for RXTX! Yes really... > esp if we can fix the Bluetooth issues. If you want to contribute documentation then the best place to do that is the wiki. If there is anything missing or that could be improved on then please do so. If there are any points that you would like to see improved, for which you don't have the knowledge then ask on the mailing list for a volunteer. Andre From florianmanschwetus at gmx.de Fri Aug 8 03:04:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Fri, 08 Aug 2008 11:04:14 +0200 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Message-ID: <489C0C0E.2020401@gmx.de> Agustin Mu?oz schrieb: > Hi, I'm still learning about serial communication and I have some > doubts. I've got this question about how to do the following thing in rxtx. > I have this hardware that connect to a PC using a serial port. These > hardware receives data from a telephone line, proccess it, and then send > it forward to the serial port. I've used a program named wincomm that > shows what information is send it through the serial port and I have the > nex behaviour: > > The hardware has a buffer where all data is stored, that cannot be sent > it through the seria port. > The program reads the first data send it by the hardware, and keep > reading the same data always. > There is a button in the application that says enable Ack, and when I > click, then the hardware start to send all the stored information, and > all the information is shown. > > I write a class, using rxtx that reads the serial port, and the same > thing happens, it remains reading the same (first) data all the time. > And I thing something like the enable Ack I'm missing. > How can I do this enable Ack from my java code using rxtx? Afaik, a look at man ascii reveals: Okt Dez Hex Char 006 6 06 ACK So, i hope this will do the job: send(6); florian > > Thanks in advance > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/5b4965f8/attachment-0036.bin From agusmunioz at gmail.com Fri Aug 8 16:31:00 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 19:31:00 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <489C0C0E.2020401@gmx.de> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> Message-ID: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Hi Florian, thanks for the answer. By send(6) you mean to get the port OutputStream and write a 6? I try that but it didn't work. Any suggestion? Thanks On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < florianmanschwetus at gmx.de> wrote: > Agustin Mu?oz schrieb: > > Hi, I'm still learning about serial communication and I have some doubts. >> I've got this question about how to do the following thing in rxtx. >> I have this hardware that connect to a PC using a serial port. These >> hardware receives data from a telephone line, proccess it, and then send it >> forward to the serial port. I've used a program named wincomm that shows >> what information is send it through the serial port and I have the nex >> behaviour: >> >> The hardware has a buffer where all data is stored, that cannot be sent >> it through the seria port. >> The program reads the first data send it by the hardware, and keep reading >> the same data always. >> There is a button in the application that says enable Ack, and when I >> click, then the hardware start to send all the stored information, and all >> the information is shown. >> >> I write a class, using rxtx that reads the serial port, and the same thing >> happens, it remains reading the same (first) data all the time. And I thing >> something like the enable Ack I'm missing. >> How can I do this enable Ack from my java code using rxtx? >> > Afaik, a look at man ascii reveals: > Okt Dez Hex Char > 006 6 06 ACK > So, i hope this will do the job: > send(6); > > florian > >> >> Thanks in advance >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/7f3fba42/attachment-0035.html From agusmunioz at gmail.com Fri Aug 8 18:39:27 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 21:39:27 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Message-ID: <988288430808081739x7f9e7889id82591d5a9e2b4f6@mail.gmail.com> Ok, Florian, it works!! my problem was that I've been sending, through the OutputStream, the bytes of 6 as a string: out.write("6".getBytes()); but then I realized that you can write an int on an OuptuStream, so I tried that and It works: out.write(6); Thank you for the guidance!! On Fri, Aug 8, 2008 at 7:31 PM, Agustin Mu?oz wrote: > Hi Florian, thanks for the answer. By send(6) you mean to get the port > OutputStream and write a 6? > > I try that but it didn't work. > > Any suggestion? > > Thanks > > > On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < > florianmanschwetus at gmx.de> wrote: > >> Agustin Mu?oz schrieb: >> >> Hi, I'm still learning about serial communication and I have some doubts. >>> I've got this question about how to do the following thing in rxtx. >>> I have this hardware that connect to a PC using a serial port. These >>> hardware receives data from a telephone line, proccess it, and then send it >>> forward to the serial port. I've used a program named wincomm that shows >>> what information is send it through the serial port and I have the nex >>> behaviour: >>> >>> The hardware has a buffer where all data is stored, that cannot be sent >>> it through the seria port. >>> The program reads the first data send it by the hardware, and keep >>> reading the same data always. >>> There is a button in the application that says enable Ack, and when I >>> click, then the hardware start to send all the stored information, and all >>> the information is shown. >>> >>> I write a class, using rxtx that reads the serial port, and the same >>> thing happens, it remains reading the same (first) data all the time. And I >>> thing something like the enable Ack I'm missing. >>> How can I do this enable Ack from my java code using rxtx? >>> >> Afaik, a look at man ascii reveals: >> Okt Dez Hex Char >> 006 6 06 ACK >> So, i hope this will do the job: >> send(6); >> >> florian >> >>> >>> Thanks in advance >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/b918ab3d/attachment-0035.html From florianmanschwetus at gmx.de Sat Aug 9 00:45:43 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Sat, 09 Aug 2008 08:45:43 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4899667C.6010706@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> Message-ID: <489D3D17.9090209@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >> Florian Manschwetus wrote: >>> Ok, sounds fine for the receiving problem. >>> But why i have to wait after each byte when sending a command squence? >>> (the for loop in send command) >> >> Hi Florian, >> I'd imagine you probably don't! You could send all bytes in one go and >> RXTX would send them. The problem is most probably the other end: >> perhaps it has a really small buffer, some non-standard UART, or a >> crazy timing issue. If you attach a terminal to your output and send >> all the bytes of a command in one go they should appear no problem. >> >> Regards, >> Michael Erskine. >> > correct with a terminal on the other end it works, my idea was that this > basic baud has some influence. Could some one explain what it is for? > > Florian To make it more clear, my problem is that i can't use: outputStream.write(byte[]); => Beamer doesn't understand the sequence. (mostly no answer when he answers then *001) when i use this construct instead: for (int i = 0; i < command.length; i++) { this.outputStream.write(command[i]); try { Thread.sleep(25); } catch (InterruptedException e) { // TODO Auto-generated catch block e.printStackTrace(); } } it works nearly reliable. So what could it be? This Basic Baud is what exactly? Florian -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080809/692304ee/attachment-0035.bin From tjarvi at qbang.org Sat Aug 9 16:37:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Aug 2008 16:37:19 -0600 (MDT) Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489D3D17.9090209@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> <489D3D17.9090209@gmx.de> Message-ID: On Sat, 9 Aug 2008, Florian Manschwetus wrote: > Florian Manschwetus schrieb: >> Michael Erskine schrieb: >>> Florian Manschwetus wrote: >>>> Ok, sounds fine for the receiving problem. >>>> But why i have to wait after each byte when sending a command squence? >>>> (the for loop in send command) >>> >>> Hi Florian, >>> I'd imagine you probably don't! You could send all bytes in one go and >>> RXTX would send them. The problem is most probably the other end: perhaps >>> it has a really small buffer, some non-standard UART, or a crazy timing >>> issue. If you attach a terminal to your output and send all the bytes of a >>> command in one go they should appear no problem. >>> >>> Regards, >>> Michael Erskine. >>> >> correct with a terminal on the other end it works, my idea was that this >> basic baud has some influence. Could some one explain what it is for? >> >> Florian > To make it more clear, > my problem is that i can't use: > outputStream.write(byte[]); > => Beamer doesn't understand the sequence. (mostly no answer when he answers > then *001) > > when i use this construct instead: > > for (int i = 0; i < command.length; i++) { > this.outputStream.write(command[i]); > try { > Thread.sleep(25); > } catch (InterruptedException e) { > // TODO Auto-generated catch block > e.printStackTrace(); > } > } > > it works nearly reliable. > > So what could it be? This Basic Baud is what exactly? > I suspect you are using the 'moon protocol' and don't know it. RXTX enables this by default. The buffer on the other end is first in first out while reading. If the buffer is full, the bits are hand carried to the moon and burried. Then if the other side reads a couple bytes, two more bytes go into the buffer followed by more moon protocol. The resulting array of bytes the other side reads may appear to be scrambled until you go to the moon, get the bits and insert them in the right place. Flow control can prevent the default moon protocol and throttles the communiation by almost writing a byte at a time as need be. Hardware flow control is preferable but software flow control should also work. Read and write can appear to hang if the other side is not connected. This is why we don't enable them all the time. If you can't use flow control, you have to take care with the moon protocol and give the other side time to read. That is what your slower version of write is doing. -- Trent Jarvi tjarvi at qbang.org From rxtx at allenjb.me.uk Mon Aug 11 08:06:36 2008 From: rxtx at allenjb.me.uk (AllenJB) Date: Mon, 11 Aug 2008 15:06:36 +0100 Subject: [Rxtx] Disabling EV_RXFLAG Message-ID: <48A0476C.2090800@allenjb.me.uk> Hi all, I'm working with a device which does not use an EvtChar and need to disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an event mask of FD 01 00 00. The reference software I have uses FB 00 00 00. With the rxtx mask I get framing errors which I believe are caused when the EvtChar is received. Is there currently a way with rxtx (I've using rxtx from Java) to disable EV_RXFLAG? If not from Java, where would I start if I wanted to turn the EV_RXFLAG option off in the C code? I've had a grep of the rxtx source code, but I can't see where EV_RXFLAG is being set. Thanks in advance, AllenJB From tjarvi at qbang.org Mon Aug 11 14:17:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Aug 2008 14:17:27 -0600 (MDT) Subject: [Rxtx] Disabling EV_RXFLAG In-Reply-To: <48A0476C.2090800@allenjb.me.uk> References: <48A0476C.2090800@allenjb.me.uk> Message-ID: On Mon, 11 Aug 2008, AllenJB wrote: > Hi all, > > I'm working with a device which does not use an EvtChar and need to > disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an > event mask of FD 01 00 00. The reference software I have uses FB 00 00 > 00. With the rxtx mask I get framing errors which I believe are caused > when the EvtChar is received. > > Is there currently a way with rxtx (I've using rxtx from Java) to > disable EV_RXFLAG? > > If not from Java, where would I start if I wanted to turn the EV_RXFLAG > option off in the C code? I've had a grep of the rxtx source code, but I > can't see where EV_RXFLAG is being set. > > Thanks in advance, > > AllenJB Hi Allen, I'd look at termios.c::tcsetattr() and termios.c::FillDCB() -- Trent Jarvi tjarvi at qbang.org From superdadusa at gmail.com Tue Aug 12 13:57:32 2008 From: superdadusa at gmail.com (John Choi) Date: Tue, 12 Aug 2008 13:57:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. Message-ID: Hi all, Just let you all know I just start to learn Java. I have download the serial comm package and the source code from open source communities.. I was able to verify with the given message string via serial monitor. when the given message string sends to the serial port then the character return added to the end of string by default if I use "Hello World" however if I changed to something else other than "Hello, World" there is no character return add to the end of string. I thing the library download from rxtx.org has implemented for the special strings. I can do like "login\n" in the string message to make character return but I don't want to add this individual custom character for each command return in every static message string I send, Can any who have done this might help me? Basically, something like this,, Write and add function to the program write a command, Reads the respond from a serial device.. Function handles multiple messages, Write: "com open" Read: Welcome to my world" expected Write: "admin" Read: Password?, expected Write: "admin" Read: you are successfully login terminal, expected. And I need to add a separate function handler handles a character return add to the each command above. If anyone can help this I can do the reset? Thank you in advance, John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0031.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SerialIO.java Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0031.pl From Steffen.DETTMER at ingenico.com Wed Aug 13 02:16:38 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 13 Aug 2008 10:16:38 +0200 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: References: Message-ID: <20080813081638.GA25412@elberon.bln.de.ingenico.com> * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > I can do like "login\n" in the string message to make character > return but I don't want to add this individual custom character > for each command return in every static message string I send, and why not?! > Can any who have done this might help me? what's about with writing a small wrapper function adding the carriage return? However, this would be slow, because either you call write two times (very bad) or the string needs to be copied, \n appended and written (since you are using Java Performance probably isn't so critical). Personally I would write `"login\n"' and `username + "\n"' etc., because since it is part of the command it should be part of the command definition string. > Basically, something like this,, Write and add function to the program write > a command, Reads the respond from a serial device.. correctly reading a `line' is more difficult. If you cannot make assumptions about timeouts and/or you need to have low delay, you need to read byte wise. If you need to save CPU resources you might need to add some buffering layer that you can read byte-wise but that is reading blockwise with some small timeout (lets say for serial lines something around byte transmission time times three or so). > /* > * To change this template, choose Tools | Templates > * and open the template in the editor. > */ :) > package joliba; > > /** > * > * @author root > */ :) > // derived from SUN's examples in the javax.comm package > import java.io.*; > import java.util.*; > //import javax.comm.*; // for SUN's serial/parallel port libraries > import gnu.io.*; // for rxtxSerial library > > public class SerialIO implements Runnable, SerialPortEventListener { > static CommPortIdentifier portId; > static CommPortIdentifier saveportId; > static Enumeration portList; > InputStream inputStream; > SerialPort serialPort; > Thread readThread; You need a thread for your synchronous RPC-style protocol? > static String messageString = "Hello, world!"; > static OutputStream outputStream; > static boolean outputBufferEmptyFlag = false; > > public static void main(String[] args) { > boolean portFound = false; > String defaultPort; > > // determine the name of the serial port on several operating systems > String osname = System.getProperty("os.name","").toLowerCase(); > if ( osname.startsWith("windows") ) { > // windows > defaultPort = "COM1"; > } else if (osname.startsWith("linux")) { > // linux > defaultPort = "/dev/ttyS0"; > } else if ( osname.startsWith("mac") ) { > // mac > defaultPort = "????"; > } else { > System.out.println("Sorry, your operating system is not supported"); > return; > } Is such a construction recommended? Isn't there some abstraction (like COM1 working on any platform)? [...] > try { > // activate the OUTPUT_BUFFER_EMPTY notifier > serialPort.notifyOnOutputEmpty(true); > } catch (Exception e) { > System.out.println("Error setting event notification"); > System.out.println(e.toString()); > System.exit(-1); > } I doubt that -1 is defined, probably some 127 or so would be the result, maybe better simply `throw e'? > public void writetoport() { > System.out.println("Writing \""+messageString+"\" to "+serialPort.getName()); > try { > // write string to serial port > outputStream.write(messageString.getBytes()); > } catch (IOException e) {} > } maybe something like /** * Writes the given output string and an additional carriage * return to the current outputStream. */ public void writeStringToPort( /** The output string (without CR). */ String output ) throws IOException { String outputLine = output + "\n"; outputStream.write(outputLine.getBytes()); } ? > > public SerialIO() { > // initalize serial port > try { > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > } catch (PortInUseException e) {} if the port is in use, you continue? Wonder that this works in Java, I would assume serialPort beeing uninitialized which AFAIK is an error in Java. > try { > inputStream = serialPort.getInputStream(); > } catch (IOException e) {} > > try { > serialPort.addEventListener(this); > } catch (TooManyListenersException e) {} > > // activate the DATA_AVAILABLE notifier > serialPort.notifyOnDataAvailable(true); > > try { > // set port parameters > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > } catch (UnsupportedCommOperationException e) {} > > // start the read thread > readThread = new Thread(this); > readThread.start(); > > } I think in all those exception cases you can abort, because it is unlikely that ignoring those errors allow a successful continuation, so in this case maybe it would be better to add a throw clause to the method. > public void run() { > // first thing in the thread, we initialize the write operation > initwritetoport(); > try { > while (true) { > // write string to port, the serialEvent will read it > writetoport(); > Thread.sleep(1000); > } > } catch (InterruptedException e) {} > } Does this make sense? Your `SimpleReadApp' writes one and the same string each second? > public void serialEvent(SerialPortEvent event) { > switch (event.getEventType()) { > case SerialPortEvent.BI: > case SerialPortEvent.OE: > case SerialPortEvent.FE: > case SerialPortEvent.PE: > case SerialPortEvent.CD: > case SerialPortEvent.CTS: > case SerialPortEvent.DSR: > case SerialPortEvent.RI: > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > break; > case SerialPortEvent.DATA_AVAILABLE: > // we get here if data has been received > byte[] readBuffer = new byte[20]; > try { > // read data > while (inputStream.available() > 0) { > int numBytes = inputStream.read(readBuffer); > } > // print data > String result = new String(readBuffer); > System.out.println("Read: "+result); > } catch (IOException e) {} I doubt that this is correct. I would assume you will get a 20 bytes result always, if more bytes would be available they would be printed in a second line but if less bytes are read I'd assume that the buffer/result contains zero bytes from implicite readBuffer contents initialisation (zero is no string terminator in Java AFAIK). > break; > } > } > } oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From florianmanschwetus at gmx.de Wed Aug 13 06:09:31 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 13 Aug 2008 14:09:31 +0200 Subject: [Rxtx] someone has seen such errors? Message-ID: <48A2CEFB.90007@gmx.de> I mean my communication mostly works, but it is far from perfect could this be the reason? Florian Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/949b9947/attachment-0031.bin From superdadusa at gmail.com Wed Aug 13 08:40:32 2008 From: superdadusa at gmail.com (John Choi) Date: Wed, 13 Aug 2008 08:40:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: <20080813081638.GA25412@elberon.bln.de.ingenico.com> References: <20080813081638.GA25412@elberon.bln.de.ingenico.com> Message-ID: Thank you so much Steffen and I will try that suggestion. John On 8/13/08, Steffen DETTMER wrote: > > * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > > I can do like "login\n" in the string message to make character > > return but I don't want to add this individual custom character > > for each command return in every static message string I send, > > and why not?! > > > Can any who have done this might help me? > > what's about with writing a small wrapper function adding the > carriage return? > However, this would be slow, because either you call write two > times (very bad) or the string needs to be copied, \n appended > and written (since you are using Java Performance probably isn't > so critical). > > Personally I would write `"login\n"' and `username + "\n"' etc., > because since it is part of the command it should be part of the > command definition string. > > > Basically, something like this,, Write and add function to the program > write > > a command, Reads the respond from a serial device.. > > correctly reading a `line' is more difficult. If you cannot make > assumptions about timeouts and/or you need to have low delay, you > need to read byte wise. If you need to save CPU resources you > might need to add some buffering layer that you can read > byte-wise but that is reading blockwise with some small timeout > (lets say for serial lines something around byte transmission > time times three or so). > > > /* > > * To change this template, choose Tools | Templates > > * and open the template in the editor. > > */ > > :) > > > package joliba; > > > > /** > > * > > * @author root > > */ > > :) > > > // derived from SUN's examples in the javax.comm package > > import java.io.*; > > import java.util.*; > > //import javax.comm.*; // for SUN's serial/parallel port libraries > > import gnu.io.*; // for rxtxSerial library > > > > public class SerialIO implements Runnable, SerialPortEventListener { > > static CommPortIdentifier portId; > > static CommPortIdentifier saveportId; > > static Enumeration portList; > > InputStream inputStream; > > SerialPort serialPort; > > Thread readThread; > > You need a thread for your synchronous RPC-style protocol? > > > static String messageString = "Hello, world!"; > > static OutputStream outputStream; > > static boolean outputBufferEmptyFlag = false; > > > > public static void main(String[] args) { > > boolean portFound = false; > > String defaultPort; > > > > // determine the name of the serial port on several operating > systems > > String osname = System.getProperty("os.name","").toLowerCase(); > > if ( osname.startsWith("windows") ) { > > // windows > > defaultPort = "COM1"; > > } else if (osname.startsWith("linux")) { > > // linux > > defaultPort = "/dev/ttyS0"; > > } else if ( osname.startsWith("mac") ) { > > // mac > > defaultPort = "????"; > > } else { > > System.out.println("Sorry, your operating system is not > supported"); > > return; > > } > > Is such a construction recommended? Isn't there some abstraction > (like COM1 working on any platform)? > > [...] > > try { > > // activate the OUTPUT_BUFFER_EMPTY notifier > > serialPort.notifyOnOutputEmpty(true); > > } catch (Exception e) { > > System.out.println("Error setting event notification"); > > System.out.println(e.toString()); > > System.exit(-1); > > } > > I doubt that -1 is defined, probably some 127 or so would be the > result, maybe better simply `throw e'? > > > public void writetoport() { > > System.out.println("Writing \""+messageString+"\" to > "+serialPort.getName()); > > try { > > // write string to serial port > > outputStream.write(messageString.getBytes()); > > } catch (IOException e) {} > > } > > maybe something like > > /** > * Writes the given output string and an additional carriage > * return to the current outputStream. > */ > public void > writeStringToPort( > /** The output string (without CR). */ > String output > ) throws IOException > { > String outputLine = output + "\n"; > outputStream.write(outputLine.getBytes()); > } > > ? > > > > > public SerialIO() { > > // initalize serial port > > try { > > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > > } catch (PortInUseException e) {} > > if the port is in use, you continue? Wonder that this works in > Java, I would assume serialPort beeing uninitialized which AFAIK > is an error in Java. > > > try { > > inputStream = serialPort.getInputStream(); > > } catch (IOException e) {} > > > > try { > > serialPort.addEventListener(this); > > } catch (TooManyListenersException e) {} > > > > // activate the DATA_AVAILABLE notifier > > serialPort.notifyOnDataAvailable(true); > > > > try { > > // set port parameters > > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > } catch (UnsupportedCommOperationException e) {} > > > > // start the read thread > > readThread = new Thread(this); > > readThread.start(); > > > > } > > I think in all those exception cases you can abort, because it is > unlikely that ignoring those errors allow a successful > continuation, so in this case maybe it would be better to add a > throw clause to the method. > > > public void run() { > > // first thing in the thread, we initialize the write operation > > initwritetoport(); > > try { > > while (true) { > > // write string to port, the serialEvent will read it > > writetoport(); > > Thread.sleep(1000); > > } > > } catch (InterruptedException e) {} > > } > > Does this make sense? Your `SimpleReadApp' writes one and the > same string each second? > > > public void serialEvent(SerialPortEvent event) { > > switch (event.getEventType()) { > > case SerialPortEvent.BI: > > case SerialPortEvent.OE: > > case SerialPortEvent.FE: > > case SerialPortEvent.PE: > > case SerialPortEvent.CD: > > case SerialPortEvent.CTS: > > case SerialPortEvent.DSR: > > case SerialPortEvent.RI: > > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > > break; > > case SerialPortEvent.DATA_AVAILABLE: > > // we get here if data has been received > > byte[] readBuffer = new byte[20]; > > try { > > // read data > > while (inputStream.available() > 0) { > > int numBytes = inputStream.read(readBuffer); > > } > > // print data > > String result = new String(readBuffer); > > System.out.println("Read: "+result); > > } catch (IOException e) {} > > I doubt that this is correct. I would assume you will get a 20 > bytes result always, if more bytes would be available they would > be printed in a second line but if less bytes are read I'd assume > that the buffer/result contains zero bytes from implicite > readBuffer contents initialisation (zero is no string terminator > in Java AFAIK). > > > break; > > } > > } > > } > > oki, > > Steffen > > About Ingenico Throughout the world businesses rely on Ingenico for secure > and expedient electronic transaction acceptance. Ingenico products leverage > proven technology, established standards and unparalleled ergonomics to > provide optimal reliability, versatility and usability. This comprehensive > range of products is complemented by a global array of services and > partnerships, enabling businesses in a number of vertical sectors to accept > transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged > information. If you are not the addressee or authorized to receive this for > the addressee, you must not use, copy, disclose or take any action based on > this message or any information herein. If you have received this message in > error, please advise the sender immediately by reply e-mail and delete this > message. Thank you for your cooperation. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/73c4135c/attachment-0030.html From ajmas at sympatico.ca Sat Aug 16 07:15:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 09:15:41 -0400 Subject: [Rxtx] someone has seen such errors? In-Reply-To: <48A2CEFB.90007@gmx.de> References: <48A2CEFB.90007@gmx.de> Message-ID: <43B5E8DA-1D93-4D90-809B-AAF35FF724C5@sympatico.ca> On 13-Aug-08, at 08:09 , Florian Manschwetus wrote: > I mean my communication mostly works, but it is far from perfect > could this be the reason? > > Florian > > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control Judging by the error messages this looks related to the driver you are using. Do a search for the following string with you favourite search engine, it should turn up a few hits: ftdi_set_termios FAILED to set databits/stopbits/parity Andre From ajmas at sympatico.ca Sat Aug 16 19:12:04 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 21:12:04 -0400 Subject: [Rxtx] Using SerialPortEvent? Message-ID: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Hi, Could someone tell me how I should be using the SerialPortEvent? Am I meant to be waiting for data and then simply reading from the inputstream? If this is the case why no just block on an inputstream read? Andr? From tjarvi at qbang.org Sat Aug 16 19:41:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 16 Aug 2008 19:41:13 -0600 (MDT) Subject: [Rxtx] Using SerialPortEvent? In-Reply-To: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> References: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Message-ID: On Sat, 16 Aug 2008, Andre-John Mas wrote: > Hi, > > Could someone tell me how I should be using the SerialPortEvent? Am I > meant to be waiting for data and then simply reading from the > inputstream? If this is the case why no just block on an inputstream > read? > Polling for data is fine also. It really depends upon what you are trying to do. For instance, if you require x bytes before reading, you can start polling after data is available. If you read on the same thread as your GUI and are waiting for data in a read, the results may be less than desirable. Java programming is 'usually' event driven rather than polling based. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sat Aug 16 20:10:39 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 22:10:39 -0400 Subject: [Rxtx] Using SerialPortEvent? In-Reply-To: References: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Message-ID: <3E495D4C-BB28-4845-A6AB-984C9A826BDF@sympatico.ca> On 16-Aug-08, at 21:41 , Trent Jarvi wrote: > On Sat, 16 Aug 2008, Andre-John Mas wrote: > >> Hi, >> >> Could someone tell me how I should be using the SerialPortEvent? Am I >> meant to be waiting for data and then simply reading from the >> inputstream? If this is the case why no just block on an inputstream >> read? >> > > Polling for data is fine also. It really depends upon what you are > trying to do. For instance, if you require x bytes before reading, > you can start polling after data is available. If you read on the > same thread as your GUI and are waiting for data in a read, the > results may be less than desirable. > > Java programming is 'usually' event driven rather than polling based. Sounds good. I thought I would use this opportunity to provide a event based version of the TwoWaySerialComm example. Could you just validate it before I add it to the Wiki: package ajmas74.experimental; import gnu.io.CommPort; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; import gnu.io.SerialPortEvent; import gnu.io.SerialPortEventListener; import java.io.IOException; import java.io.InputStream; import java.io.OutputStream; /** * This version of the TwoWaySerialComm example makes use of the * SerialPortEventListener to avoid polling. * * @author ajmas * */ public class TwoWaySerialComm { public TwoWaySerialComm() { super(); } void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { CommPort commPort = portIdentifier.open(this.getClass().getName(),2000); if ( commPort instanceof SerialPort ) { SerialPort serialPort = (SerialPort) commPort; serialPort .setSerialPortParams (57600 ,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); (new Thread(new SerialWriter(out))).start(); serialPort.addEventListener(new SerialReader(in)); } else { System.out.println("Error: Only serial ports are handled by this example."); } } } /** * Handles the input coming from the serial port. A new line character * is treated as the end of a block in this example. */ public static class SerialReader implements SerialPortEventListener { private InputStream in; private byte[] buffer = new byte[1024]; public SerialReader ( InputStream in ) { this.in = in; } public void serialEvent(SerialPortEvent arg0) { int data; try { int len = 0; while ( ( data = in.read()) > -1 ) { if ( data != '\n' ) { break; } buffer[len++] = (byte) data; } System.out.print(new String(buffer,0,len)); } catch ( IOException e ) { e.printStackTrace(); System.exit(-1); } } } /** */ public static class SerialWriter implements Runnable { OutputStream out; public SerialWriter ( OutputStream out ) { this.out = out; } public void run () { try { int c = 0; while ( ( c = System.in.read()) > -1 ) { this.out.write(c); } } catch ( IOException e ) { e.printStackTrace(); System.exit(-1); } } } public static void main ( String[] args ) { try { (new TwoWaySerialComm()).connect("COM3"); } catch ( Exception e ) { e.printStackTrace(); } } } From lfarkas at lfarkas.org Tue Aug 19 07:32:59 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Tue, 19 Aug 2008 15:32:59 +0200 Subject: [Rxtx] JNI or CNI Message-ID: <48AACB8B.9060606@lfarkas.org> hi, what is the current recommended way to rxtx on linux JNI or it's better to use CNI? is the CNI version fully functional and the same level as the JNI? i currently try to make a rhel/centos/fedora rpm for rxtx but has many problems with the standard dir structure. yours. -- Levente "Si vis pacem para bellum!" From lfarkas at lfarkas.org Tue Aug 19 08:47:34 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Tue, 19 Aug 2008 16:47:34 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel Message-ID: <48AADD06.7040809@lfarkas.org> hi, newer or not so newer linux kernel do not contain the UTS_RELEASE so the current rxtx is not compile on the latest kernels. even if it's commented out in the cvs configure there are other places. i attcahed a patch which fix it (or at least doesn't cause error at non-debug build). ps. is there any plan to the new 2.1-8 release in the near future? there are many changes (at least the license change in all file and in this case create a diff is very difficult)? the latest release more then 2 years old:-( -- Levente "Si vis pacem para bellum!" -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-2.1-uts.patch Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080819/ab5d38ac/attachment-0024.pl From ajmas at sympatico.ca Tue Aug 19 16:21:53 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 19 Aug 2008 18:21:53 -0400 Subject: [Rxtx] Event based example Message-ID: <24735BFB-B088-4B84-8173-FE98DF63B12F@sympatico.ca> Hi, I have just posted an example of using SerialPortEventListener in the Wiki: http://rxtx.qbang.org/wiki/index.php/Event_Based_Two_Way_Communication If you see any issues please could you let me know, or makes the changes. Andre From Martin.Oberhuber at windriver.com Fri Aug 22 04:02:24 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 22 Aug 2008 12:02:24 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <48AADD06.7040809@lfarkas.org> References: <48AADD06.7040809@lfarkas.org> Message-ID: <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> Farkas, there are indeed efforts to get a new RXTX release out the door. Your experience as a package maintainer would likely be helpful during these efforts, since I'd think it makes sense to keep the patches minimal that you must make to have the source compile in your environment. What are the things that you find problematic, apart from the UTS thing that you have mentioned before? What is the timing that you have in mind for your package? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Farkas Levente > Sent: Tuesday, August 19, 2008 4:48 PM > To: rxtx at qbang.org > Subject: [Rxtx] UTS_RELEASE not defined in newer kernel > > hi, > newer or not so newer linux kernel do not contain the > UTS_RELEASE so the > current rxtx is not compile on the latest kernels. even if it's > commented out in the cvs configure there are other places. > i attcahed a patch which fix it (or at least doesn't cause error at > non-debug build). > > ps. is there any plan to the new 2.1-8 release in the near > future? there > are many changes (at least the license change in all file and in this > case create a diff is very difficult)? the latest release more then 2 > years old:-( > > -- > Levente "Si vis pacem para bellum!" > From lfarkas at lfarkas.org Fri Aug 22 04:36:26 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Fri, 22 Aug 2008 12:36:26 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> References: <48AADD06.7040809@lfarkas.org> <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> Message-ID: <48AE96AA.6090505@lfarkas.org> hi, the packages already build for fedora-9 and centos-5 and here: http://www.lfarkas.org/linux/packages/ what i've to patch, the UTS, the configure script, but it's already fixed in the cvs (in another way) and the loadlibrary. the reasons for last one can be found here: https://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_files_that_use_JNI after we test it i'd like to add these packages to fedora and epel main repository (that's why it's be useful a new release after 2 years:-) imho versions are cheap and why not just release 2.1-8? the real code changes are minimal and if something critical bug found still can release 2.1-9:-) ps. and would be better to use simple number for version like 2.1-7 rather then 2.1-7v2. Oberhuber, Martin wrote: > Farkas, > > there are indeed efforts to get a new RXTX release out the > door. Your experience as a package maintainer would likely > be helpful during these efforts, since I'd think it makes > sense to keep the patches minimal that you must make to > have the source compile in your environment. > > What are the things that you find problematic, apart from > the UTS thing that you have mentioned before? > > What is the timing that you have in mind for your package? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >> On Behalf Of Farkas Levente >> Sent: Tuesday, August 19, 2008 4:48 PM >> To: rxtx at qbang.org >> Subject: [Rxtx] UTS_RELEASE not defined in newer kernel >> >> hi, >> newer or not so newer linux kernel do not contain the >> UTS_RELEASE so the >> current rxtx is not compile on the latest kernels. even if it's >> commented out in the cvs configure there are other places. >> i attcahed a patch which fix it (or at least doesn't cause error at >> non-debug build). >> >> ps. is there any plan to the new 2.1-8 release in the near >> future? there >> are many changes (at least the license change in all file and in this >> case create a diff is very difficult)? the latest release more then 2 >> years old:-( >> >> -- >> Levente "Si vis pacem para bellum!" >> -- Levente "Si vis pacem para bellum!" From tjarvi at qbang.org Fri Aug 22 18:50:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Aug 2008 18:50:32 -0600 (MDT) Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <48AE96AA.6090505@lfarkas.org> References: <48AADD06.7040809@lfarkas.org> <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> <48AE96AA.6090505@lfarkas.org> Message-ID: Hi Farkas, The v2 was simply the second build - no code changes. We are comming out with a new release shortly. I would encourage working with distros as you are. The building of rxtx turns out to be a bottle neck in quick releases. We do want stable releases that work for a year or more but I would have no problems with quicker cycles on developing work. I would have no problem working with someone that did builds that receive less testing more often but they do have to come out for multiple platforms from this end. Thanks for the links. On Fri, 22 Aug 2008, Farkas Levente wrote: > hi, > the packages already build for fedora-9 and centos-5 and here: > http://www.lfarkas.org/linux/packages/ > what i've to patch, the UTS, the configure script, but it's already > fixed in the cvs (in another way) and the loadlibrary. the reasons for > last one can be found here: > https://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_files_that_use_JNI > after we test it i'd like to add these packages to fedora and epel main > repository (that's why it's be useful a new release after 2 years:-) > imho versions are cheap and why not just release 2.1-8? the real code > changes are minimal and if something critical bug found still can > release 2.1-9:-) > > ps. and would be better to use simple number for version like 2.1-7 > rather then 2.1-7v2. > > Oberhuber, Martin wrote: >> Farkas, >> >> there are indeed efforts to get a new RXTX release out the >> door. Your experience as a package maintainer would likely >> be helpful during these efforts, since I'd think it makes >> sense to keep the patches minimal that you must make to >> have the source compile in your environment. >> >> What are the things that you find problematic, apart from >> the UTS thing that you have mentioned before? >> >> What is the timing that you have in mind for your package? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >>> On Behalf Of Farkas Levente >>> Sent: Tuesday, August 19, 2008 4:48 PM >>> To: rxtx at qbang.org >>> Subject: [Rxtx] UTS_RELEASE not defined in newer kernel >>> >>> hi, >>> newer or not so newer linux kernel do not contain the >>> UTS_RELEASE so the >>> current rxtx is not compile on the latest kernels. even if it's >>> commented out in the cvs configure there are other places. >>> i attcahed a patch which fix it (or at least doesn't cause error at >>> non-debug build). >>> >>> ps. is there any plan to the new 2.1-8 release in the near >>> future? there >>> are many changes (at least the license change in all file and in this >>> case create a diff is very difficult)? the latest release more then 2 >>> years old:-( >>> >>> -- >>> Levente "Si vis pacem para bellum!" >>> > > > From andy at triera.net Sat Aug 23 15:17:44 2008 From: andy at triera.net (Andy Rozman) Date: Sat, 23 Aug 2008 21:17:44 +0000 Subject: [Rxtx] port not identified on FreeBSD In-Reply-To: References: Message-ID: <48B07E78.2030306@triera.net> Hi ! I have one small problem... I have started using FreeBSD in last few days and I have come accross a problem with rxtx on FreeBSD. I am using usb-to-serial converter, which is identified under FreeBSD without problem as ucom0, and creates link under /dev called ttyU0, which is correct way to be done under FreeBSD (if device would be unidentified it would be called ugen0 - as usb generic). Problem is that I say to rxtx to get my all serial ports this one is not among them. Which names are permissable under linux-like implementations? Which will be accepted as serial ports? Andy From tjarvi at qbang.org Sat Aug 23 13:57:45 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 23 Aug 2008 13:57:45 -0600 (MDT) Subject: [Rxtx] port not identified on FreeBSD In-Reply-To: <48B07E78.2030306@triera.net> References: <48B07E78.2030306@triera.net> Message-ID: On Sat, 23 Aug 2008, Andy Rozman wrote: > Hi ! > > I have one small problem... I have started using FreeBSD in last few > days and I have come accross a problem with rxtx on FreeBSD. > > I am using usb-to-serial converter, which is identified under FreeBSD > without problem as ucom0, and creates link under /dev called > ttyU0, which is correct way to be done under FreeBSD (if device would be > unidentified it would be called ugen0 - as usb generic). Problem is that > I say to rxtx to get my all serial ports this one is not among them. > Which names are permissable under linux-like implementations? Which will > be accepted as serial ports? > > Andy > Thanks Andy! We will add ttyU* to FreeBSD. For now you can use properties to enable the port. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting#How_does_rxtx_detect_ports.3F__Can_I_override_it.3F The fix: diff -u -r1.16.2.59 RXTXCommDriver.java --- RXTXCommDriver.java 18 Nov 2007 22:32:41 -0000 1.16.2.59 +++ RXTXCommDriver.java 23 Aug 2008 19:55:25 -0000 @@ -644,6 +644,7 @@ { String[] Temp = { "ttyd", //general purpose serial ports + "ttyU", //general purpose USB serial ports "cuaa", //dialout serial ports "ttyA", //Specialix SI/XIO dialin ports "cuaA", //Specialix SI/XIO dialout ports -- Trent Jarvi tjarvi at qbang.org From rick_knight at rlknight.com Mon Aug 4 13:25:10 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Mon, 04 Aug 2008 12:25:10 -0700 Subject: [Rxtx] Sun's Comm API? Message-ID: <48975796.4010600@rlknight.com> I have an application that requires the javax compatible version of RXTX and Sun's comm api. I've been able to download and extract the version of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api anywhere. Can someone tell me where I can find it? Or maybe send me a copy? Also, when I try to build RXTX, configure and make complete successfully but make install failes with this error libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 I've never come accross this error before. How can I get past it? Thanks, Rick From bboyes at systronix.com Mon Aug 4 19:10:01 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:10:01 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48975796.4010600@rlknight.com> References: <48975796.4010600@rlknight.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/cb9c6167/attachment-0040.html From bboyes at systronix.com Mon Aug 4 19:12:37 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:12:37 -0600 Subject: [Rxtx] Towards an RXTX release - CSR BT/USB chipset In-Reply-To: <488FB7E7.8000802@gmail.com> References: <460801A4097E3D4CA04CC64EE648584806C56CF0@ism-mail03.corp.ad.wrs.com> <13557-75390@sneakemail.com> <20980-23424@sneakemail.com> <488FB7E7.8000802@gmail.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/52236088/attachment-0040.html From tjarvi at qbang.org Mon Aug 4 19:42:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 19:42:21 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: On Mon, 4 Aug 2008, Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: > I have an application that requires the javax compatible > version of RXTX > and Sun's comm api. I've been able to download and extract > the version > of RXTX that I need (2.0-7pre2) but I can't find Sun's camm > api > anywhere. Can someone tell me where I can find it? Or maybe > send me a > > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm port > support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have just > a ZIP with only the .class JAR file - no source or docs), has a readme > with these comments: > > This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release.? The 2.0.3 release itself is > no longer distributed.? comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project.? The RxTx project (http://www.rxtx.org ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org) was opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support.? Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins.? Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > ? > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > I hope that is helpful! > It would be nice to work with Sun to resolve those longstanding issues. But it may not be practical unless the process goes as fast and painless as the grandfathering of commapi did. Another option may be the old kaffe extensions that moved to gnu classpathx. These don't have the native libraries but should provide the 2.0 interface and the javax.comm.properties mechansim for SPI. http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Mon Aug 4 20:23:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Mon, 04 Aug 2008 20:23:57 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4897B9BD.5070809@ergotech.com> Has there been any work/would it be possible, to layer a javacomm look-alike on top of the GNU code? The goal is not to move the javax code forward, but to emulate the "legacy" javax packages for people who still need this. Jim Trent Jarvi wrote: > On Mon, 4 Aug 2008, Bruce Boyes wrote: > >> At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible >> version of RXTX >> and Sun's comm api. I've been able to download and extract >> the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm >> api >> anywhere. Can someone tell me where I can find it? Or maybe >> send me a >> >> >> javaxcomm has had a sort of on-again off-again history. The windoze >> version has been languishing for years (literally) but there are newer >> versions for other OS's. >> >> We try to keep links on one of our help pages current: >> http://www.practicalembeddedjava.com/tools/javatools_list.html >> which gets you to here: >> http://java.sun.com/products/javacomm/ >> where it says in fact they no longer even support Windows and Mac: >> "Implementations of the API are currently available for Solaris SPARC, >> Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so >> someone could support it. But I guess that's part of the reason RXTX >> exists! >> >> So one of Sun's own products, SunSPOT, has to use RXTX to get comm port >> support. >> >> The version we use is 2.0 from 11/15/1998. I have posted it on our >> website, which is within the terms of the license agreement contained >> therein (as I understand it). >> >> The last version of javaxcomm for Windows, 2.0.3, (for which I have just >> a ZIP with only the .class JAR file - no source or docs), has a readme >> with these comments: >> >> This distribution contains the comm.jar file original part >> of the COMMAPI 2.0.3 release. The 2.0.3 release itself is >> no longer distributed. comm.jar, which contains the comm >> API java class files (eg. Sun's binary implementation of the >> interface classes), is being made available, unsupported, >> with no obligation to fix bugs, at the request of the RXTX >> project. The RxTx project (http://www.rxtx.org ), uses the >> comm.jar class files, but provides their own native library >> components to provide support for other platforms. >> >> The 2.0.3 comm.jar is being provided in this way because >> as of COMMAPI 3.x, the java binary implementation forked and >> became incompatible with the RxTx project's native code. >> Due to the lack of a clear business case, and to resource >> constraints, no additional resources are being >> provided to provide an alternative engineering solution >> at the time of writing. >> >> RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: >> >> Ultimately the COMMAPI would be better served if a Java >> Community Process JSR (http://www.jcp.org) was opened and >> the COMMAPI was rearchitected to provide a more pluggable >> framework to improve cross-platform support. Such an >> architecture would embody a better defined and better >> documented SPI interface, including a way for comm. ports >> to be revealed to the client application through the API >> via platform-aware plugins. Similarly, native code used >> to access comm port in general could be handled more >> flexibly using a plugin model, whereby on any platform, >> multiple native modules could be in use simultaneously. >> >> Since there are now various ways serial ports can be implemented >> and accessed, modular comm. port JNI native libraries would be >> of benefit insofar as removing the burden of over-generalization >> from any single native component, or inversely, by relieving the >> implicit constraint that comm. drivers be accessed only via a >> monolithic mechanism, such as the UNIX vnode interface. >> >> paul.klissner at sun.com >> 6/10/06 >> >> I hope that is helpful! >> > > It would be nice to work with Sun to resolve those longstanding issues. > But it may not be practical unless the process goes as fast and painless > as the grandfathering of commapi did. > > Another option may be the old kaffe extensions that moved to gnu > classpathx. These don't have the native libraries but should provide > the 2.0 interface and the javax.comm.properties mechansim for SPI. > > http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Mon Aug 4 21:09:15 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 21:09:15 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? Message-ID: Hi Jim, I will not step into the javax.comm namespace without Sun's explicite permission. I fully understand the pain point you are trying to address. In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm Linux) - which remains an integral part of rxtx. At the time it was a win for Sun and rxtx. The Sun commapi license is/was fairly clear that rxtx should not step into that namespace. It made sense as Sun was active in that space and rxtx may go into another namespace - it was an experiment in working with Sun. This may sound silly looking at something that happened almost 10 years ago. In a community of respect which Sun helped create, there is no question about what to do. I hope eventually Sun will step up and do a right thing too. I agree that this is hurting the API more than helping it. There are also questions about how to replace the API in the long term which includes HID support which isn't going well so far. Others that can't even look at Sun's javax.comm today and can look at Kaffe's contribution to classpathx can easily work around such restrictions. On Mon, 4 Aug 2008, Jim Redman wrote: > Has there been any work/would it be possible, to layer a javacomm > look-alike on top of the GNU code? > > The goal is not to move the javax code forward, but to emulate the > "legacy" javax packages for people who still need this. > > Jim > > Trent Jarvi wrote: >> >> It would be nice to work with Sun to resolve those longstanding issues. >> But it may not be practical unless the process goes as fast and painless >> as the grandfathering of commapi did. >> >> Another option may be the old kaffe extensions that moved to gnu >> classpathx. These don't have the native libraries but should provide >> the 2.0 interface and the javax.comm.properties mechansim for SPI. >> >> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From florianmanschwetus at gmx.de Tue Aug 5 05:04:46 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 13:04:46 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: References: <48971C1F.9020806@gmx.de> Message-ID: <489833CE.1040801@gmx.de> Just look at sendCommand in this method I have to place a Thread.sleep(20) after each byte send to get working. Even the event based receive doesn't work fine but this could be may stupidness. The specifikation document (it is on the last pages of the manual) for the beamer could be found on: http://www.optoma.co.uk/support.aspx Florian Manschwetus Trent Jarvi schrieb: > > Hi Florian > > Sorry for the top post in advance. I worry you may not see my answer > under all your code :) > > I have not received this email before. This is 500k of code which I > don't have time to read. I can spend about 5 min on each hobby email > and still get to work in the morning. I have a couple suggestions for > how to get an answer. > > First, cut out your comments and extra code so you can demonstrate the > question (I might even glance and see what is wrong then). Don't go for > a working final product. Isolate the problem using a simple program and > then ask with that as an example. If I did what you just did, I'd have > to post 3/4 of a million lines of code :) > > Second, join the rxtx mail-list and ask there. This will give you 100x > more eyes. I'll also read and try to follow. > > -- > taj > > > > On Mon, 4 Aug 2008, Florian Manschwetus wrote: > >> It could be that my university account is blocked by filters so >> resending from here. >> >> >> Topic is to control Optoma HD80 beamer using rs232 serial chat. >> This code is able to detect power state and switch the beamer on / off. >> connected is the beamer using a digitus usb 2.0 serial adapter with an >> FT232 USB-Serial adapter the systems architecture is amd64. >> >> Please take a look in the sendCommand routine i have to place theire >> those Thread.sleep to get it working. >> Now the question is this correct or is there a better way to get this >> working correctly? >> >> In the javadoc coming with the install i found this: >> setBaudBase >> >> public boolean setBaudBase(int BaudBase) >> throws UnsupportedCommOperationException, >> java.io.IOException >> >> Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 >> before using. >> >> could this explain the error? >> I attached my java source and the protocol description for the beamer >> (available on vendor website). >> >> thx, >> Florian Manschwetus >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: TestRS232.java Type: text/x-java Size: 9143 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0080.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0081.bin From michael.erskine at ketech.com Tue Aug 5 05:53:49 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Tue, 5 Aug 2008 12:53:49 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489833CE.1040801@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> > Just look at sendCommand in this method I have to place a > Thread.sleep(20) after each byte send to get working. Even the event > based receive doesn't work fine but this could be may stupidness. Hi Florian, Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. Regards, Michael Erskine. From florianmanschwetus at gmx.de Tue Aug 5 07:28:15 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:28:15 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> Message-ID: <4898556F.8000208@gmx.de> Michael Erskine schrieb: >> Just look at sendCommand in this method I have to place a >> Thread.sleep(20) after each byte send to get working. Even the event >> based receive doesn't work fine but this could be may stupidness. > > Hi Florian, > > Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. > > Regards, > Michael Erskine. > Ok, sounds fine for the receiving problem. But why i have to wait after each byte when sending a command squence? (the for loop in send command) Florian > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/284f350c/attachment-0039.bin From florianmanschwetus at gmx.de Tue Aug 5 07:44:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:44:14 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <4898592E.2020908@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >>> Just look at sendCommand in this method I have to place a >>> Thread.sleep(20) after each byte send to get working. Even the event >>> based receive doesn't work fine but this could be may stupidness. >> >> Hi Florian, >> >> Yes, naturally you'll have to wait for a response from the other end. >> Why not wait for notification from the event thread perhaps using a >> BlockingDeque rather than your LinkedList. Generally I >> try to decouple all input and output streams: in your case your >> application is operating synchronously like the "expect" program >> (http://expect.nist.gov/) so waits (or timeouts) will need to be >> factored in. >> >> Regards, >> Michael Erskine. >> > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) > > Florian Furthermore there is this basic baud with this confusing javadoc entry: public boolean setBaudBase(int BaudBase) throws UnsupportedCommOperationException, java.io.IOException Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 before using. maybe this could explain something Florian >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/006c7425/attachment-0039.bin From jredman at ergotech.com Tue Aug 5 09:13:36 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 05 Aug 2008 09:13:36 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: Message-ID: <48986E20.3060104@ergotech.com> Trent, So two issues: 1) Technically I'm still not sure how easy/practical a layer would be. The problems are always classes like listeners, and wrapping returns of gnu.io classes. I really see it as a "delegate" type of concept. Any thoughts or ideas of the practicality of this approach? The idea is not to modify RXTX. 2) Javax. The javax namespace does seem to be in widespread use outside of Sun (the same is true for the java namespace). The classpath extensions, or some other location, should be interested in a JavaComm implementation even if it does have dependencies on RXTX. Would you have any philosophical objection to an approach like that? Of course, I suspect it might be better if someone with that authority at Sun would admit that the javax namespace is already in the wild and that there is no problem with it being used within RXTX. Jim Trent Jarvi wrote: > Hi Jim, > > I will not step into the javax.comm namespace without Sun's explicite > permission. I fully understand the pain point you are trying to address. > > In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm > Linux) - which remains an integral part of rxtx. At the time it was a win for > Sun and rxtx. > > The Sun commapi license is/was fairly clear that rxtx should not step into that > namespace. It made sense as Sun was active in that space and rxtx may go into > another namespace - it was an experiment in working with Sun. > > This may sound silly looking at something that happened almost 10 years ago. > In a community of respect which Sun helped create, there is no question about > what to do. I hope eventually Sun will step up and do a right thing too. > > I agree that this is hurting the API more than helping it. There are also > questions about how to replace the API in the long term which includes HID > support which isn't going well so far. > > Others that can't even look at Sun's javax.comm today and can look at Kaffe's > contribution to classpathx can easily work around such restrictions. > > On Mon, 4 Aug 2008, Jim Redman wrote: > >> Has there been any work/would it be possible, to layer a javacomm >> look-alike on top of the GNU code? >> >> The goal is not to move the javax code forward, but to emulate the >> "legacy" javax packages for people who still need this. >> >> Jim >> >> Trent Jarvi wrote: >>> It would be nice to work with Sun to resolve those longstanding issues. >>> But it may not be practical unless the process goes as fast and painless >>> as the grandfathering of commapi did. >>> >>> Another option may be the old kaffe extensions that moved to gnu >>> classpathx. These don't have the native libraries but should provide >>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>> >>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From sandeep at genevasoftech.com Tue Aug 5 11:18:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Tue, 05 Aug 2008 22:48:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <48988B6C.5080409@genevasoftech.com> Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. *-- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/ad20f1cb/attachment-0039.html From Martin.Oberhuber at windriver.com Tue Aug 5 13:30:17 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Tue, 5 Aug 2008 21:30:17 +0200 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Sandeep, shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on Sol7 but I've successfully run it on Sol9 and Sol10. Or is your request really about a native 64bit variant? I'm afraid that then you're out of luck since I think that quite a bit of RXTX is not yet ready for 64 bit. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Sandeep Kumar K Sent: Tuesday, August 05, 2008 7:19 PM To: rxtx at qbang.org Subject: [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so for Solaris 9 Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. -- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/81b7f988/attachment-0039.html From tjarvi at qbang.org Tue Aug 5 22:38:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 22:38:34 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 5 Aug 2008, Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built > on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid that > then > you're out of luck since I think that quite a bit of RXTX is not yet > ready > for 64 bit. > While rxtx-2.1-7 probably has problems, The CVS code should be OK for 64 bit Solaris. If it isn't, let me know and I'll find which patch is missing. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Aug 5 23:13:00 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 23:13:00 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48986E20.3060104@ergotech.com> References: <48986E20.3060104@ergotech.com> Message-ID: On Tue, 5 Aug 2008, Jim Redman wrote: > Trent, > > So two issues: > > 1) Technically I'm still not sure how easy/practical a layer would be. The > problems are always classes like listeners, and wrapping returns of gnu.io > classes. I really see it as a "delegate" type of concept. Any thoughts or > ideas of the practicality of this approach? The idea is not to modify RXTX. I have not put too much thought into this. I assume you want what rxtx 2.0 provided to tie into javax.comm implementations. More classes could be added to rxtx 2.1-7 for SPI support. Maintaining rxtx-2.0 could also be handed to someone if they like. > > 2) Javax. The javax namespace does seem to be in widespread use outside of > Sun (the same is true for the java namespace). The classpath extensions, or > some other location, should be interested in a JavaComm implementation even > if it does have dependencies on RXTX. Would you have any philosophical > objection to an approach like that? > No problems. Classpathx would be a possible place to do it. I'd suggest thinking twice about what this involves in practical terms. You would be wanting to revive the 2.0 API while Sun is at 3.0 and grandfathering the JSR. This undermines the main reason (established api) for using the javax.comm namespace and does not leave such a project in a good position. The only win I see here is maintaining support for applications that can't migrate namespaces. Not that that isn't important. At some point it is going to be less work to just edit the bytecode :) Such a javax.comm effort would also be signing up new projects that decided to use the work up for concerns they probably will not understand or expect. That probably isn't a good path to facilitate for new projects at this time. We will put a good faith effort to work well with others but keep in mind the project has limited bandwidth for such efforts. > Of course, I suspect it might be better if someone with that authority at Sun > would admit that the javax namespace is already in the wild and that there is > no problem with it being used within RXTX. > > Jim > > Trent Jarvi wrote: >> Hi Jim, >> >> I will not step into the javax.comm namespace without Sun's explicite >> permission. I fully understand the pain point you are trying to address. >> >> In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java >> Comm Linux) - which remains an integral part of rxtx. At the time it was a >> win for Sun and rxtx. >> >> The Sun commapi license is/was fairly clear that rxtx should not step into >> that namespace. It made sense as Sun was active in that space and rxtx may >> go into another namespace - it was an experiment in working with Sun. >> >> This may sound silly looking at something that happened almost 10 years >> ago. In a community of respect which Sun helped create, there is no >> question about what to do. I hope eventually Sun will step up and do a >> right thing too. >> >> I agree that this is hurting the API more than helping it. There are also >> questions about how to replace the API in the long term which includes HID >> support which isn't going well so far. >> >> Others that can't even look at Sun's javax.comm today and can look at >> Kaffe's contribution to classpathx can easily work around such >> restrictions. >> >> On Mon, 4 Aug 2008, Jim Redman wrote: >> >>> Has there been any work/would it be possible, to layer a javacomm >>> look-alike on top of the GNU code? >>> >>> The goal is not to move the javax code forward, but to emulate the >>> "legacy" javax packages for people who still need this. >>> >>> Jim >>> >>> Trent Jarvi wrote: >>>> It would be nice to work with Sun to resolve those longstanding issues. >>>> But it may not be practical unless the process goes as fast and painless >>>> as the grandfathering of commapi did. >>>> >>>> Another option may be the old kaffe extensions that moved to gnu >>>> classpathx. These don't have the native libraries but should provide >>>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>>> >>>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From sandeep at genevasoftech.com Wed Aug 6 00:03:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Wed, 06 Aug 2008 11:33:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: <48993EB8.30107@genevasoftech.com> Thank you Mr. Martin for your suggestion. The native file which is given in rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am getting the following error . Any suggestions to solve this issue. I am using Solaris SPARC 64 bit machine. ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) thrown while loading gnu.io.RXTXCommDriver Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(Unknown Source) at java.lang.ClassLoader.loadLibrary(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) at com.ReadFromModem.main(ReadFromModem.java:84) * * *Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid > that then > you're out of luck since I think that quite a bit of RXTX is not yet ready > for 64 bit. > > Cheers, > -- > *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > ------------------------------------------------------------------------ > *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On > Behalf Of *Sandeep Kumar K > *Sent:* Tuesday, August 05, 2008 7:19 PM > *To:* rxtx at qbang.org > *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so > for Solaris 9 > > Hi, > > Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 > bit machine. The librxtxSerial.so given in website is for Solaris 8. > > *-- > > Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/1e920343/attachment-0039.html From tjarvi at qbang.org Wed Aug 6 00:21:42 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 00:21:42 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <48993EB8.30107@genevasoftech.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> <48993EB8.30107@genevasoftech.com> Message-ID: Hi Sandeep You may be out of luck unless you can compile the 2.1 src in CVS (requires gnu make and gcc). But you could try the ToyBox(R)(TM) which is a collection of WiLdLy untested cross compiled 2.1-7 binaries covering everything from the ibm z series to embeded arm/ppc. To give an idea how poorly these are tested, I don't even know if z series machines have a serial port. ftp://www.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Solaris They should at least match the binary types. Actually, I think if you use the rxtx jar from CVS with that file, it should 'work' as the fix for 64 bits was in java not the native code. You could just cd rxtx*/src; javac *.java then jar -cf RXTXcomm.jar `find -name \*.class` to create the hybrid which will complain about version information a bit. On Wed, 6 Aug 2008, Sandeep Kumar K wrote: > Thank you Mr. Martin for your suggestion. The native file which is given in > rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am > getting the following error . > Any suggestions to solve this issue. > I am using Solaris SPARC 64 bit machine. > > ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar > java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 > (Possible cause: architecture word > width mismatch) thrown while loading gnu.io.RXTXCommDriver > Exception in thread "main" java.lang.UnsatisfiedLinkError: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF > class: ELFCLASS64 (Possible cause: > architecture word width mismatch) > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(Unknown Source) > at java.lang.ClassLoader.loadLibrary(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > at com.ReadFromModem.main(ReadFromModem.java:84) > > * > * > > *Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > > > Oberhuber, Martin wrote: >> Sandeep, >> shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse >> variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on >> Sol7 but I've successfully run it on Sol9 and Sol10. >> Or is your request really about a native 64bit variant? I'm afraid that >> then >> you're out of luck since I think that quite a bit of RXTX is not yet ready >> for 64 bit. >> Cheers, >> -- >> *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> ------------------------------------------------------------------------ >> *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On >> Behalf Of *Sandeep Kumar K >> *Sent:* Tuesday, August 05, 2008 7:19 PM >> *To:* rxtx at qbang.org >> *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so >> for Solaris 9 >> >> Hi, >> >> Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 >> bit machine. The librxtxSerial.so given in website is for Solaris 8. >> >> *-- >> Thanks & Regards >> >> Sandeep Kumar K >> Sr. Software Engineer >> Geneva Software Technologies >> Whitefield, Bangalore >> Mob : 9880193454* >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> From michael.erskine at ketech.com Wed Aug 6 01:39:28 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 6 Aug 2008 08:39:28 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Florian Manschwetus wrote: > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) Hi Florian, I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. Regards, Michael Erskine. From florianmanschwetus at gmx.de Wed Aug 6 02:53:16 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 06 Aug 2008 10:53:16 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Message-ID: <4899667C.6010706@gmx.de> Michael Erskine schrieb: > Florian Manschwetus wrote: >> Ok, sounds fine for the receiving problem. >> But why i have to wait after each byte when sending a command squence? >> (the for loop in send command) > > Hi Florian, > I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. > > Regards, > Michael Erskine. > correct with a terminal on the other end it works, my idea was that this basic baud has some influence. Could some one explain what it is for? Florian > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/c2b4fa84/attachment-0039.bin From rick_knight at rlknight.com Wed Aug 6 13:01:07 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:01:07 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F4F3.3020707@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > I have an application (Readerware) that uses RXTX with Javax to access the serial port. This used to work fine under previous Linux' and Java, but something has changed, I assume with Java itself , that is causing the application to fail with a link error. The application is not able to find librxtxSerialParallel.so. RXTX supplies librxtxSerial.so and librxtxParallel.so, but not librxtxSerialParallel.so. Where can I get librxtxSerialParallel.so, or do I need it? Is something else causing the lib to not be found? Thanks, Rick Knight From rick_knight at rlknight.com Wed Aug 6 13:17:55 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:17:55 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F8E3.5060400@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Thanks for the reply. The developer of the app I'm trying to use (Readerware) has sent me a copy of the comm.api and I've copied the library (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar into the proper places. When I try to run the application, I get this error... Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: /usr/lib/libSolarisSerialParallel.so: /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not little-endian (Possible cause: endianness mismatch) Caught java.lang.UnsatisfiedLinkError: com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I while loading driver com.sun.comm.SolarisDriver Is there a way around this error? Thanks again, Rick Knight From jlar310 at gmail.com Wed Aug 6 13:37:42 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 14:37:42 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899F8E3.5060400@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > The developer of the app I'm trying to use (Readerware) has sent me a > copy of the comm.api and I've copied the library > (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar > into the proper places. When I try to run the application, I get this > error... > > Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: > /usr/lib/libSolarisSerialParallel.so: > /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not > little-endian (Possible cause: endianness mismatch) > Caught java.lang.UnsatisfiedLinkError: > com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I > > while loading driver com.sun.comm.SolarisDriver > > Is there a way around this error? What host OS are you running? From your original post it looks like 32 bit Linux. The libSolarisSerialParallel.so file is for Sun Solaris and will vary depending on the underlying hardware architecture as well. Sorry for the double post Rick, but I failed to send this to the list the first time... -- Jeff From rick_knight at rlknight.com Wed Aug 6 13:44:29 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:44:29 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: <4899FF1D.9030504@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > > >> The developer of the app I'm trying to use (Readerware) has sent me a >> copy of the comm.api and I've copied the library >> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >> into the proper places. When I try to run the application, I get this >> error... >> >> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >> /usr/lib/libSolarisSerialParallel.so: >> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >> little-endian (Possible cause: endianness mismatch) >> Caught java.lang.UnsatisfiedLinkError: >> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >> >> while loading driver com.sun.comm.SolarisDriver >> >> Is there a way around this error? >> > > What host OS are you running? From your original post it looks like 32 > bit Linux. > > The libSolarisSerialParallel.so file is for Sun Solaris and will vary > depending on the underlying hardware architecture as well. > > I'm running Kubuntu Linux (debian based). It's 32 bit. Rick Knight From jlar310 at gmail.com Wed Aug 6 15:33:23 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 16:33:23 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > I don't think Sun did binary libraries for Linux in the 2.0 version. Can someone with more historical experience than I confirm that? I recently tried to port a Comm API application from Solaris sparc to Linux x86 and likewise could not get my hands on the binary libraries. I eventually just re-wrote the code to use the gnu namespace packages and rxtx 2.1. What I don't understand is why your application vendor does not provide everything you need to run their software. FYI: I have librxtxParallel.so and librxtxSerial.so installed at JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is /usr/java/default which is actually a softlink to /usr/java/jre1.6.0_05. -- Jeff From defiantlew at yahoo.com.au Wed Aug 6 16:29:33 2008 From: defiantlew at yahoo.com.au (Lew L) Date: Thu, 7 Aug 2008 08:29:33 +1000 Subject: [Rxtx] Sun's Comm API Documentation References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> Message-ID: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> As a matter of interest is the Sun Comm API documentation available somewhere? I have tried the Sun site but it seems to have been removed. Unless I have missed the documentation for RXTX? I javadocced the RXTX source but information (to me) is minimal. Somewhere I got the impression that the Sun Comm API docs is, or was, compatible with RXTX, what is the best docs to use in conjuntion with RXTX and where may the be available? Cheers Lew From rick_knight at rlknight.com Wed Aug 6 17:18:33 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:18:33 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A3149.4050306@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff I'm not sure if I posted this here or not, but when I try to build RXTX from source I get this install error... make all-am make[1]: Entering directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' make[1]: Nothing to be done for `all-am'. make[1]: Leaving directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 Can you tell me how to get past this error and get RXTX built and installed? Thanks, Rick From bboyes at systronix.com Wed Aug 6 17:40:12 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Wed, 06 Aug 2008 17:40:12 -0600 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: At 16:29 08/06/2008, Lew L wrote: >As a matter of interest is the Sun Comm API documentation available >somewhere? I have tried the Sun site but it seems to have been removed. It's in the file we have posted, link in prev email (sorry, in a huge hurry right now). Javadocs definitely there. >Unless I have missed the documentation for RXTX? I javadocced the RXTX >source but information (to me) is minimal. >Somewhere I got the impression that the Sun Comm API docs is, or was, >compatible with RXTX, what is the best docs to use in conjuntion with RXTX >and where may the be available? Yeah, this is one of my concerns/beefs. There is little documentation for RXTX and it isn't just the same as javaxcomm. I would be willing to help out writing docs for RXTX! Yes really... esp if we can fix the Bluetooth issues. best regards Bruce >Cheers >Lew > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx ------- WWW.SYSTRONIX.COM ---------- Real embedded Java and much more +1-801-534-1017 Salt Lake City, USA From rick_knight at rlknight.com Wed Aug 6 17:54:08 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:54:08 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A39A0.2090309@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff, I would like for my vendor to switch to rxtx 2.1. It would make things much easier for me. I'm not sure why he's still using the javax compatible code. He's a small operation. Re-writing the code to use gnu namespace sounds like a major overhaul. Was it? Thanks, Rick From tjarvi at qbang.org Wed Aug 6 21:35:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:35:12 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: >> >>> Jeff wrote: >>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>>> >>>> >>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things > much easier for me. I'm not sure why he's still using the javax > compatible code. He's a small operation. Re-writing the code to use gnu > namespace sounds like a major overhaul. Was it? > Hi Jeff, The changes are fairly mechanical. Imports need to change and any explicite use of the namespace needs to change such as catching an exception. The following script was made for maintaining rxtx 2.0 but can apply to other needs. It is in the contrib dir with rxtx source. #!/bin/sh # Don't use! :) # # Sat, 03 May 2003 16:45:08 Modifications from J?rg Weule # Create a ed-cmd for the change of one pattern # case $1 in gnu) X=g/javax_comm/s+javax_comm+gnu_io+g ;; javax) X=g/gnu_io/s+gnu_io+javax_comm+g ;; *) echo;echo;echo From the top rxtx directory run;echo;echo -e \\t./ChangePackage.sh gnu;echo -e \\t\\tor;echo -e \\t./ChangePackage.sh javax;echo;echo; exit 0 ;; esac # # ed will be used to keep the owner and mode of the files unchanged. # We have run the ed-script for the characters '.' '/' as well. # "tr _ $D" do the change. # find . -type f -a -print | grep -v $0 | (while read F ; do ( echo $X; echo $X| tr _ /; echo $X| tr _ .; echo w; echo q ) | ed $F 2>&1 >/dev/null done ) # # Now we do little changes at the Makefiles. Hope that all we need. # find . -name Makefile\* -a -print | (while read F ; do cat < References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: On Thu, 7 Aug 2008, Lew L wrote: > As a matter of interest is the Sun Comm API documentation available > somewhere? I have tried the Sun site but it seems to have been removed. > > Unless I have missed the documentation for RXTX? I javadocced the RXTX > source but information (to me) is minimal. > Somewhere I got the impression that the Sun Comm API docs is, or was, > compatible with RXTX, what is the best docs to use in conjuntion with RXTX > and where may the be available? > Hi Lew, The documentation on Sun's website is accurate. The changes that are problematic in 3.0 are on the backside which rxtx used to plug into. http://java.sun.com/products/javacomm/reference/api/index.html CommPortIdentifier may have some minor differences (judging by the authors notes). -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Aug 6 21:46:08 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:46:08 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > If javax.comm.properties is properly installed and you are using a 2.0 version of Sun's commapi with rxtx 2.0, you should not see the library attempt to load libSolarisSerialParallel.so. Sun CommAPI 3.0 will not work with any version of rxtx as it is hard coded to use the shared library. See the INSTALL file with rxtx-2.0 source for more help with the properties file. -- Trent Jarvi tjarvi at qbang.org From jlar310 at gmail.com Thu Aug 7 06:32:06 2008 From: jlar310 at gmail.com (Jeff) Date: Thu, 7 Aug 2008 07:32:06 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > Jeff wrote: >> >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >> wrote: >> >>> >>> Jeff wrote: >>> >>>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>> wrote: >>>> >>>> >>>> >>>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things much > easier for me. I'm not sure why he's still using the javax compatible code. > He's a small operation. Re-writing the code to use gnu namespace sounds like > a major overhaul. Was it? I found it quite easy. In fact, in order to accommodate the transition, I actually separated all of the code that deals directly with the Comm API or RXTX into a helper class. The helper class was then coded to use reflection to determine which library was available and then instantiate the necessary objects. No direct imports of either library are used. The main application just needs to get it's hands on the IO streams and need not deal directly with the libraries. Other programs may not be so simple... But this doesn't really help you unless your vendor forks over the source code... -- Jeff From rick_knight at rlknight.com Thu Aug 7 09:47:12 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Thu, 07 Aug 2008 08:47:12 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: <489B1900.10108@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >>> wrote: >>> >>> >>>> Jeff wrote: >>>> >>>> >>>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>>> copy of the comm.api and I've copied the library >>>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>>> into the proper places. When I try to run the application, I get this >>>>>> error... >>>>>> >>>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>>> /usr/lib/libSolarisSerialParallel.so: >>>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>>> little-endian (Possible cause: endianness mismatch) >>>>>> Caught java.lang.UnsatisfiedLinkError: >>>>>> >>>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>>> >>>>>> while loading driver com.sun.comm.SolarisDriver >>>>>> >>>>>> Is there a way around this error? >>>>>> >>>>>> >>>>>> >>>>> What host OS are you running? From your original post it looks like 32 >>>>> bit Linux. >>>>> >>>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>>> depending on the underlying hardware architecture as well. >>>>> >>>>> >>>>> >>>>> >>>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>>> >>>> >>>> >>> I don't think Sun did binary libraries for Linux in the 2.0 version. >>> Can someone with more historical experience than I confirm that? >>> >>> I recently tried to port a Comm API application from Solaris sparc to >>> Linux x86 and likewise could not get my hands on the binary libraries. >>> I eventually just re-wrote the code to use the gnu namespace packages >>> and rxtx 2.1. >>> >>> What I don't understand is why your application vendor does not >>> provide everything you need to run their software. >>> >>> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >>> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >>> /usr/java/default which is actually a softlink to >>> /usr/java/jre1.6.0_05. >>> >>> >>> >> Jeff, >> >> I would like for my vendor to switch to rxtx 2.1. It would make things much >> easier for me. I'm not sure why he's still using the javax compatible code. >> He's a small operation. Re-writing the code to use gnu namespace sounds like >> a major overhaul. Was it? >> > > I found it quite easy. In fact, in order to accommodate the > transition, I actually separated all of the code that deals directly > with the Comm API or RXTX into a helper class. The helper class was > then coded to use reflection to determine which library was available > and then instantiate the necessary objects. No direct imports of > either library are used. The main application just needs to get it's > hands on the IO streams and need not deal directly with the libraries. > Other programs may not be so simple... > > But this doesn't really help you unless your vendor forks over the > source code... > > Jeff, This may not help me directly, but I'm going to forward this thread to the vendor. I think he'll be open to making things work. Thanks again, Rick Knight From agusmunioz at gmail.com Thu Aug 7 16:39:51 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Thu, 7 Aug 2008 19:39:51 -0300 Subject: [Rxtx] How to send ack? Message-ID: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Hi, I'm still learning about serial communication and I have some doubts. I've got this question about how to do the following thing in rxtx. I have this hardware that connect to a PC using a serial port. These hardware receives data from a telephone line, proccess it, and then send it forward to the serial port. I've used a program named wincomm that shows what information is send it through the serial port and I have the nex behaviour: The hardware has a buffer where all data is stored, that cannot be sent it through the seria port. The program reads the first data send it by the hardware, and keep reading the same data always. There is a button in the application that says enable Ack, and when I click, then the hardware start to send all the stored information, and all the information is shown. I write a class, using rxtx that reads the serial port, and the same thing happens, it remains reading the same (first) data all the time. And I thing something like the enable Ack I'm missing. How can I do this enable Ack from my java code using rxtx? Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080807/e0a0f9a1/attachment-0037.html From ajmas at sympatico.ca Thu Aug 7 18:26:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 7 Aug 2008 20:26:41 -0400 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: <4BF42297-81E2-4BB8-A89F-1D43588379AE@sympatico.ca> On 6-Aug-08, at 19:40 , Bruce Boyes wrote: >> Unless I have missed the documentation for RXTX? I javadocced the >> RXTX >> source but information (to me) is minimal. >> Somewhere I got the impression that the Sun Comm API docs is, or was, >> compatible with RXTX, what is the best docs to use in conjuntion >> with RXTX >> and where may the be available? > > Yeah, this is one of my concerns/beefs. There is little documentation > for RXTX and it isn't just the same as javaxcomm. > > I would be willing to help out writing docs for RXTX! Yes really... > esp if we can fix the Bluetooth issues. If you want to contribute documentation then the best place to do that is the wiki. If there is anything missing or that could be improved on then please do so. If there are any points that you would like to see improved, for which you don't have the knowledge then ask on the mailing list for a volunteer. Andre From florianmanschwetus at gmx.de Fri Aug 8 03:04:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Fri, 08 Aug 2008 11:04:14 +0200 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Message-ID: <489C0C0E.2020401@gmx.de> Agustin Mu?oz schrieb: > Hi, I'm still learning about serial communication and I have some > doubts. I've got this question about how to do the following thing in rxtx. > I have this hardware that connect to a PC using a serial port. These > hardware receives data from a telephone line, proccess it, and then send > it forward to the serial port. I've used a program named wincomm that > shows what information is send it through the serial port and I have the > nex behaviour: > > The hardware has a buffer where all data is stored, that cannot be sent > it through the seria port. > The program reads the first data send it by the hardware, and keep > reading the same data always. > There is a button in the application that says enable Ack, and when I > click, then the hardware start to send all the stored information, and > all the information is shown. > > I write a class, using rxtx that reads the serial port, and the same > thing happens, it remains reading the same (first) data all the time. > And I thing something like the enable Ack I'm missing. > How can I do this enable Ack from my java code using rxtx? Afaik, a look at man ascii reveals: Okt Dez Hex Char 006 6 06 ACK So, i hope this will do the job: send(6); florian > > Thanks in advance > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/5b4965f8/attachment-0037.bin From agusmunioz at gmail.com Fri Aug 8 16:31:00 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 19:31:00 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <489C0C0E.2020401@gmx.de> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> Message-ID: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Hi Florian, thanks for the answer. By send(6) you mean to get the port OutputStream and write a 6? I try that but it didn't work. Any suggestion? Thanks On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < florianmanschwetus at gmx.de> wrote: > Agustin Mu?oz schrieb: > > Hi, I'm still learning about serial communication and I have some doubts. >> I've got this question about how to do the following thing in rxtx. >> I have this hardware that connect to a PC using a serial port. These >> hardware receives data from a telephone line, proccess it, and then send it >> forward to the serial port. I've used a program named wincomm that shows >> what information is send it through the serial port and I have the nex >> behaviour: >> >> The hardware has a buffer where all data is stored, that cannot be sent >> it through the seria port. >> The program reads the first data send it by the hardware, and keep reading >> the same data always. >> There is a button in the application that says enable Ack, and when I >> click, then the hardware start to send all the stored information, and all >> the information is shown. >> >> I write a class, using rxtx that reads the serial port, and the same thing >> happens, it remains reading the same (first) data all the time. And I thing >> something like the enable Ack I'm missing. >> How can I do this enable Ack from my java code using rxtx? >> > Afaik, a look at man ascii reveals: > Okt Dez Hex Char > 006 6 06 ACK > So, i hope this will do the job: > send(6); > > florian > >> >> Thanks in advance >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/7f3fba42/attachment-0036.html From agusmunioz at gmail.com Fri Aug 8 18:39:27 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 21:39:27 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Message-ID: <988288430808081739x7f9e7889id82591d5a9e2b4f6@mail.gmail.com> Ok, Florian, it works!! my problem was that I've been sending, through the OutputStream, the bytes of 6 as a string: out.write("6".getBytes()); but then I realized that you can write an int on an OuptuStream, so I tried that and It works: out.write(6); Thank you for the guidance!! On Fri, Aug 8, 2008 at 7:31 PM, Agustin Mu?oz wrote: > Hi Florian, thanks for the answer. By send(6) you mean to get the port > OutputStream and write a 6? > > I try that but it didn't work. > > Any suggestion? > > Thanks > > > On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < > florianmanschwetus at gmx.de> wrote: > >> Agustin Mu?oz schrieb: >> >> Hi, I'm still learning about serial communication and I have some doubts. >>> I've got this question about how to do the following thing in rxtx. >>> I have this hardware that connect to a PC using a serial port. These >>> hardware receives data from a telephone line, proccess it, and then send it >>> forward to the serial port. I've used a program named wincomm that shows >>> what information is send it through the serial port and I have the nex >>> behaviour: >>> >>> The hardware has a buffer where all data is stored, that cannot be sent >>> it through the seria port. >>> The program reads the first data send it by the hardware, and keep >>> reading the same data always. >>> There is a button in the application that says enable Ack, and when I >>> click, then the hardware start to send all the stored information, and all >>> the information is shown. >>> >>> I write a class, using rxtx that reads the serial port, and the same >>> thing happens, it remains reading the same (first) data all the time. And I >>> thing something like the enable Ack I'm missing. >>> How can I do this enable Ack from my java code using rxtx? >>> >> Afaik, a look at man ascii reveals: >> Okt Dez Hex Char >> 006 6 06 ACK >> So, i hope this will do the job: >> send(6); >> >> florian >> >>> >>> Thanks in advance >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/b918ab3d/attachment-0036.html From florianmanschwetus at gmx.de Sat Aug 9 00:45:43 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Sat, 09 Aug 2008 08:45:43 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4899667C.6010706@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> Message-ID: <489D3D17.9090209@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >> Florian Manschwetus wrote: >>> Ok, sounds fine for the receiving problem. >>> But why i have to wait after each byte when sending a command squence? >>> (the for loop in send command) >> >> Hi Florian, >> I'd imagine you probably don't! You could send all bytes in one go and >> RXTX would send them. The problem is most probably the other end: >> perhaps it has a really small buffer, some non-standard UART, or a >> crazy timing issue. If you attach a terminal to your output and send >> all the bytes of a command in one go they should appear no problem. >> >> Regards, >> Michael Erskine. >> > correct with a terminal on the other end it works, my idea was that this > basic baud has some influence. Could some one explain what it is for? > > Florian To make it more clear, my problem is that i can't use: outputStream.write(byte[]); => Beamer doesn't understand the sequence. (mostly no answer when he answers then *001) when i use this construct instead: for (int i = 0; i < command.length; i++) { this.outputStream.write(command[i]); try { Thread.sleep(25); } catch (InterruptedException e) { // TODO Auto-generated catch block e.printStackTrace(); } } it works nearly reliable. So what could it be? This Basic Baud is what exactly? Florian -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080809/692304ee/attachment-0036.bin From tjarvi at qbang.org Sat Aug 9 16:37:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Aug 2008 16:37:19 -0600 (MDT) Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489D3D17.9090209@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> <489D3D17.9090209@gmx.de> Message-ID: On Sat, 9 Aug 2008, Florian Manschwetus wrote: > Florian Manschwetus schrieb: >> Michael Erskine schrieb: >>> Florian Manschwetus wrote: >>>> Ok, sounds fine for the receiving problem. >>>> But why i have to wait after each byte when sending a command squence? >>>> (the for loop in send command) >>> >>> Hi Florian, >>> I'd imagine you probably don't! You could send all bytes in one go and >>> RXTX would send them. The problem is most probably the other end: perhaps >>> it has a really small buffer, some non-standard UART, or a crazy timing >>> issue. If you attach a terminal to your output and send all the bytes of a >>> command in one go they should appear no problem. >>> >>> Regards, >>> Michael Erskine. >>> >> correct with a terminal on the other end it works, my idea was that this >> basic baud has some influence. Could some one explain what it is for? >> >> Florian > To make it more clear, > my problem is that i can't use: > outputStream.write(byte[]); > => Beamer doesn't understand the sequence. (mostly no answer when he answers > then *001) > > when i use this construct instead: > > for (int i = 0; i < command.length; i++) { > this.outputStream.write(command[i]); > try { > Thread.sleep(25); > } catch (InterruptedException e) { > // TODO Auto-generated catch block > e.printStackTrace(); > } > } > > it works nearly reliable. > > So what could it be? This Basic Baud is what exactly? > I suspect you are using the 'moon protocol' and don't know it. RXTX enables this by default. The buffer on the other end is first in first out while reading. If the buffer is full, the bits are hand carried to the moon and burried. Then if the other side reads a couple bytes, two more bytes go into the buffer followed by more moon protocol. The resulting array of bytes the other side reads may appear to be scrambled until you go to the moon, get the bits and insert them in the right place. Flow control can prevent the default moon protocol and throttles the communiation by almost writing a byte at a time as need be. Hardware flow control is preferable but software flow control should also work. Read and write can appear to hang if the other side is not connected. This is why we don't enable them all the time. If you can't use flow control, you have to take care with the moon protocol and give the other side time to read. That is what your slower version of write is doing. -- Trent Jarvi tjarvi at qbang.org From rxtx at allenjb.me.uk Mon Aug 11 08:06:36 2008 From: rxtx at allenjb.me.uk (AllenJB) Date: Mon, 11 Aug 2008 15:06:36 +0100 Subject: [Rxtx] Disabling EV_RXFLAG Message-ID: <48A0476C.2090800@allenjb.me.uk> Hi all, I'm working with a device which does not use an EvtChar and need to disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an event mask of FD 01 00 00. The reference software I have uses FB 00 00 00. With the rxtx mask I get framing errors which I believe are caused when the EvtChar is received. Is there currently a way with rxtx (I've using rxtx from Java) to disable EV_RXFLAG? If not from Java, where would I start if I wanted to turn the EV_RXFLAG option off in the C code? I've had a grep of the rxtx source code, but I can't see where EV_RXFLAG is being set. Thanks in advance, AllenJB From tjarvi at qbang.org Mon Aug 11 14:17:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Aug 2008 14:17:27 -0600 (MDT) Subject: [Rxtx] Disabling EV_RXFLAG In-Reply-To: <48A0476C.2090800@allenjb.me.uk> References: <48A0476C.2090800@allenjb.me.uk> Message-ID: On Mon, 11 Aug 2008, AllenJB wrote: > Hi all, > > I'm working with a device which does not use an EvtChar and need to > disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an > event mask of FD 01 00 00. The reference software I have uses FB 00 00 > 00. With the rxtx mask I get framing errors which I believe are caused > when the EvtChar is received. > > Is there currently a way with rxtx (I've using rxtx from Java) to > disable EV_RXFLAG? > > If not from Java, where would I start if I wanted to turn the EV_RXFLAG > option off in the C code? I've had a grep of the rxtx source code, but I > can't see where EV_RXFLAG is being set. > > Thanks in advance, > > AllenJB Hi Allen, I'd look at termios.c::tcsetattr() and termios.c::FillDCB() -- Trent Jarvi tjarvi at qbang.org From superdadusa at gmail.com Tue Aug 12 13:57:32 2008 From: superdadusa at gmail.com (John Choi) Date: Tue, 12 Aug 2008 13:57:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. Message-ID: Hi all, Just let you all know I just start to learn Java. I have download the serial comm package and the source code from open source communities.. I was able to verify with the given message string via serial monitor. when the given message string sends to the serial port then the character return added to the end of string by default if I use "Hello World" however if I changed to something else other than "Hello, World" there is no character return add to the end of string. I thing the library download from rxtx.org has implemented for the special strings. I can do like "login\n" in the string message to make character return but I don't want to add this individual custom character for each command return in every static message string I send, Can any who have done this might help me? Basically, something like this,, Write and add function to the program write a command, Reads the respond from a serial device.. Function handles multiple messages, Write: "com open" Read: Welcome to my world" expected Write: "admin" Read: Password?, expected Write: "admin" Read: you are successfully login terminal, expected. And I need to add a separate function handler handles a character return add to the each command above. If anyone can help this I can do the reset? Thank you in advance, John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0032.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SerialIO.java Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0032.pl From Steffen.DETTMER at ingenico.com Wed Aug 13 02:16:38 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 13 Aug 2008 10:16:38 +0200 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: References: Message-ID: <20080813081638.GA25412@elberon.bln.de.ingenico.com> * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > I can do like "login\n" in the string message to make character > return but I don't want to add this individual custom character > for each command return in every static message string I send, and why not?! > Can any who have done this might help me? what's about with writing a small wrapper function adding the carriage return? However, this would be slow, because either you call write two times (very bad) or the string needs to be copied, \n appended and written (since you are using Java Performance probably isn't so critical). Personally I would write `"login\n"' and `username + "\n"' etc., because since it is part of the command it should be part of the command definition string. > Basically, something like this,, Write and add function to the program write > a command, Reads the respond from a serial device.. correctly reading a `line' is more difficult. If you cannot make assumptions about timeouts and/or you need to have low delay, you need to read byte wise. If you need to save CPU resources you might need to add some buffering layer that you can read byte-wise but that is reading blockwise with some small timeout (lets say for serial lines something around byte transmission time times three or so). > /* > * To change this template, choose Tools | Templates > * and open the template in the editor. > */ :) > package joliba; > > /** > * > * @author root > */ :) > // derived from SUN's examples in the javax.comm package > import java.io.*; > import java.util.*; > //import javax.comm.*; // for SUN's serial/parallel port libraries > import gnu.io.*; // for rxtxSerial library > > public class SerialIO implements Runnable, SerialPortEventListener { > static CommPortIdentifier portId; > static CommPortIdentifier saveportId; > static Enumeration portList; > InputStream inputStream; > SerialPort serialPort; > Thread readThread; You need a thread for your synchronous RPC-style protocol? > static String messageString = "Hello, world!"; > static OutputStream outputStream; > static boolean outputBufferEmptyFlag = false; > > public static void main(String[] args) { > boolean portFound = false; > String defaultPort; > > // determine the name of the serial port on several operating systems > String osname = System.getProperty("os.name","").toLowerCase(); > if ( osname.startsWith("windows") ) { > // windows > defaultPort = "COM1"; > } else if (osname.startsWith("linux")) { > // linux > defaultPort = "/dev/ttyS0"; > } else if ( osname.startsWith("mac") ) { > // mac > defaultPort = "????"; > } else { > System.out.println("Sorry, your operating system is not supported"); > return; > } Is such a construction recommended? Isn't there some abstraction (like COM1 working on any platform)? [...] > try { > // activate the OUTPUT_BUFFER_EMPTY notifier > serialPort.notifyOnOutputEmpty(true); > } catch (Exception e) { > System.out.println("Error setting event notification"); > System.out.println(e.toString()); > System.exit(-1); > } I doubt that -1 is defined, probably some 127 or so would be the result, maybe better simply `throw e'? > public void writetoport() { > System.out.println("Writing \""+messageString+"\" to "+serialPort.getName()); > try { > // write string to serial port > outputStream.write(messageString.getBytes()); > } catch (IOException e) {} > } maybe something like /** * Writes the given output string and an additional carriage * return to the current outputStream. */ public void writeStringToPort( /** The output string (without CR). */ String output ) throws IOException { String outputLine = output + "\n"; outputStream.write(outputLine.getBytes()); } ? > > public SerialIO() { > // initalize serial port > try { > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > } catch (PortInUseException e) {} if the port is in use, you continue? Wonder that this works in Java, I would assume serialPort beeing uninitialized which AFAIK is an error in Java. > try { > inputStream = serialPort.getInputStream(); > } catch (IOException e) {} > > try { > serialPort.addEventListener(this); > } catch (TooManyListenersException e) {} > > // activate the DATA_AVAILABLE notifier > serialPort.notifyOnDataAvailable(true); > > try { > // set port parameters > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > } catch (UnsupportedCommOperationException e) {} > > // start the read thread > readThread = new Thread(this); > readThread.start(); > > } I think in all those exception cases you can abort, because it is unlikely that ignoring those errors allow a successful continuation, so in this case maybe it would be better to add a throw clause to the method. > public void run() { > // first thing in the thread, we initialize the write operation > initwritetoport(); > try { > while (true) { > // write string to port, the serialEvent will read it > writetoport(); > Thread.sleep(1000); > } > } catch (InterruptedException e) {} > } Does this make sense? Your `SimpleReadApp' writes one and the same string each second? > public void serialEvent(SerialPortEvent event) { > switch (event.getEventType()) { > case SerialPortEvent.BI: > case SerialPortEvent.OE: > case SerialPortEvent.FE: > case SerialPortEvent.PE: > case SerialPortEvent.CD: > case SerialPortEvent.CTS: > case SerialPortEvent.DSR: > case SerialPortEvent.RI: > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > break; > case SerialPortEvent.DATA_AVAILABLE: > // we get here if data has been received > byte[] readBuffer = new byte[20]; > try { > // read data > while (inputStream.available() > 0) { > int numBytes = inputStream.read(readBuffer); > } > // print data > String result = new String(readBuffer); > System.out.println("Read: "+result); > } catch (IOException e) {} I doubt that this is correct. I would assume you will get a 20 bytes result always, if more bytes would be available they would be printed in a second line but if less bytes are read I'd assume that the buffer/result contains zero bytes from implicite readBuffer contents initialisation (zero is no string terminator in Java AFAIK). > break; > } > } > } oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From florianmanschwetus at gmx.de Wed Aug 13 06:09:31 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 13 Aug 2008 14:09:31 +0200 Subject: [Rxtx] someone has seen such errors? Message-ID: <48A2CEFB.90007@gmx.de> I mean my communication mostly works, but it is far from perfect could this be the reason? Florian Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/949b9947/attachment-0032.bin From superdadusa at gmail.com Wed Aug 13 08:40:32 2008 From: superdadusa at gmail.com (John Choi) Date: Wed, 13 Aug 2008 08:40:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: <20080813081638.GA25412@elberon.bln.de.ingenico.com> References: <20080813081638.GA25412@elberon.bln.de.ingenico.com> Message-ID: Thank you so much Steffen and I will try that suggestion. John On 8/13/08, Steffen DETTMER wrote: > > * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > > I can do like "login\n" in the string message to make character > > return but I don't want to add this individual custom character > > for each command return in every static message string I send, > > and why not?! > > > Can any who have done this might help me? > > what's about with writing a small wrapper function adding the > carriage return? > However, this would be slow, because either you call write two > times (very bad) or the string needs to be copied, \n appended > and written (since you are using Java Performance probably isn't > so critical). > > Personally I would write `"login\n"' and `username + "\n"' etc., > because since it is part of the command it should be part of the > command definition string. > > > Basically, something like this,, Write and add function to the program > write > > a command, Reads the respond from a serial device.. > > correctly reading a `line' is more difficult. If you cannot make > assumptions about timeouts and/or you need to have low delay, you > need to read byte wise. If you need to save CPU resources you > might need to add some buffering layer that you can read > byte-wise but that is reading blockwise with some small timeout > (lets say for serial lines something around byte transmission > time times three or so). > > > /* > > * To change this template, choose Tools | Templates > > * and open the template in the editor. > > */ > > :) > > > package joliba; > > > > /** > > * > > * @author root > > */ > > :) > > > // derived from SUN's examples in the javax.comm package > > import java.io.*; > > import java.util.*; > > //import javax.comm.*; // for SUN's serial/parallel port libraries > > import gnu.io.*; // for rxtxSerial library > > > > public class SerialIO implements Runnable, SerialPortEventListener { > > static CommPortIdentifier portId; > > static CommPortIdentifier saveportId; > > static Enumeration portList; > > InputStream inputStream; > > SerialPort serialPort; > > Thread readThread; > > You need a thread for your synchronous RPC-style protocol? > > > static String messageString = "Hello, world!"; > > static OutputStream outputStream; > > static boolean outputBufferEmptyFlag = false; > > > > public static void main(String[] args) { > > boolean portFound = false; > > String defaultPort; > > > > // determine the name of the serial port on several operating > systems > > String osname = System.getProperty("os.name","").toLowerCase(); > > if ( osname.startsWith("windows") ) { > > // windows > > defaultPort = "COM1"; > > } else if (osname.startsWith("linux")) { > > // linux > > defaultPort = "/dev/ttyS0"; > > } else if ( osname.startsWith("mac") ) { > > // mac > > defaultPort = "????"; > > } else { > > System.out.println("Sorry, your operating system is not > supported"); > > return; > > } > > Is such a construction recommended? Isn't there some abstraction > (like COM1 working on any platform)? > > [...] > > try { > > // activate the OUTPUT_BUFFER_EMPTY notifier > > serialPort.notifyOnOutputEmpty(true); > > } catch (Exception e) { > > System.out.println("Error setting event notification"); > > System.out.println(e.toString()); > > System.exit(-1); > > } > > I doubt that -1 is defined, probably some 127 or so would be the > result, maybe better simply `throw e'? > > > public void writetoport() { > > System.out.println("Writing \""+messageString+"\" to > "+serialPort.getName()); > > try { > > // write string to serial port > > outputStream.write(messageString.getBytes()); > > } catch (IOException e) {} > > } > > maybe something like > > /** > * Writes the given output string and an additional carriage > * return to the current outputStream. > */ > public void > writeStringToPort( > /** The output string (without CR). */ > String output > ) throws IOException > { > String outputLine = output + "\n"; > outputStream.write(outputLine.getBytes()); > } > > ? > > > > > public SerialIO() { > > // initalize serial port > > try { > > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > > } catch (PortInUseException e) {} > > if the port is in use, you continue? Wonder that this works in > Java, I would assume serialPort beeing uninitialized which AFAIK > is an error in Java. > > > try { > > inputStream = serialPort.getInputStream(); > > } catch (IOException e) {} > > > > try { > > serialPort.addEventListener(this); > > } catch (TooManyListenersException e) {} > > > > // activate the DATA_AVAILABLE notifier > > serialPort.notifyOnDataAvailable(true); > > > > try { > > // set port parameters > > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > } catch (UnsupportedCommOperationException e) {} > > > > // start the read thread > > readThread = new Thread(this); > > readThread.start(); > > > > } > > I think in all those exception cases you can abort, because it is > unlikely that ignoring those errors allow a successful > continuation, so in this case maybe it would be better to add a > throw clause to the method. > > > public void run() { > > // first thing in the thread, we initialize the write operation > > initwritetoport(); > > try { > > while (true) { > > // write string to port, the serialEvent will read it > > writetoport(); > > Thread.sleep(1000); > > } > > } catch (InterruptedException e) {} > > } > > Does this make sense? Your `SimpleReadApp' writes one and the > same string each second? > > > public void serialEvent(SerialPortEvent event) { > > switch (event.getEventType()) { > > case SerialPortEvent.BI: > > case SerialPortEvent.OE: > > case SerialPortEvent.FE: > > case SerialPortEvent.PE: > > case SerialPortEvent.CD: > > case SerialPortEvent.CTS: > > case SerialPortEvent.DSR: > > case SerialPortEvent.RI: > > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > > break; > > case SerialPortEvent.DATA_AVAILABLE: > > // we get here if data has been received > > byte[] readBuffer = new byte[20]; > > try { > > // read data > > while (inputStream.available() > 0) { > > int numBytes = inputStream.read(readBuffer); > > } > > // print data > > String result = new String(readBuffer); > > System.out.println("Read: "+result); > > } catch (IOException e) {} > > I doubt that this is correct. I would assume you will get a 20 > bytes result always, if more bytes would be available they would > be printed in a second line but if less bytes are read I'd assume > that the buffer/result contains zero bytes from implicite > readBuffer contents initialisation (zero is no string terminator > in Java AFAIK). > > > break; > > } > > } > > } > > oki, > > Steffen > > About Ingenico Throughout the world businesses rely on Ingenico for secure > and expedient electronic transaction acceptance. Ingenico products leverage > proven technology, established standards and unparalleled ergonomics to > provide optimal reliability, versatility and usability. This comprehensive > range of products is complemented by a global array of services and > partnerships, enabling businesses in a number of vertical sectors to accept > transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged > information. If you are not the addressee or authorized to receive this for > the addressee, you must not use, copy, disclose or take any action based on > this message or any information herein. If you have received this message in > error, please advise the sender immediately by reply e-mail and delete this > message. Thank you for your cooperation. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/73c4135c/attachment-0031.html From ajmas at sympatico.ca Sat Aug 16 07:15:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 09:15:41 -0400 Subject: [Rxtx] someone has seen such errors? In-Reply-To: <48A2CEFB.90007@gmx.de> References: <48A2CEFB.90007@gmx.de> Message-ID: <43B5E8DA-1D93-4D90-809B-AAF35FF724C5@sympatico.ca> On 13-Aug-08, at 08:09 , Florian Manschwetus wrote: > I mean my communication mostly works, but it is far from perfect > could this be the reason? > > Florian > > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control Judging by the error messages this looks related to the driver you are using. Do a search for the following string with you favourite search engine, it should turn up a few hits: ftdi_set_termios FAILED to set databits/stopbits/parity Andre From ajmas at sympatico.ca Sat Aug 16 19:12:04 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 21:12:04 -0400 Subject: [Rxtx] Using SerialPortEvent? Message-ID: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Hi, Could someone tell me how I should be using the SerialPortEvent? Am I meant to be waiting for data and then simply reading from the inputstream? If this is the case why no just block on an inputstream read? Andr? From tjarvi at qbang.org Sat Aug 16 19:41:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 16 Aug 2008 19:41:13 -0600 (MDT) Subject: [Rxtx] Using SerialPortEvent? In-Reply-To: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> References: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Message-ID: On Sat, 16 Aug 2008, Andre-John Mas wrote: > Hi, > > Could someone tell me how I should be using the SerialPortEvent? Am I > meant to be waiting for data and then simply reading from the > inputstream? If this is the case why no just block on an inputstream > read? > Polling for data is fine also. It really depends upon what you are trying to do. For instance, if you require x bytes before reading, you can start polling after data is available. If you read on the same thread as your GUI and are waiting for data in a read, the results may be less than desirable. Java programming is 'usually' event driven rather than polling based. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sat Aug 16 20:10:39 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 22:10:39 -0400 Subject: [Rxtx] Using SerialPortEvent? In-Reply-To: References: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Message-ID: <3E495D4C-BB28-4845-A6AB-984C9A826BDF@sympatico.ca> On 16-Aug-08, at 21:41 , Trent Jarvi wrote: > On Sat, 16 Aug 2008, Andre-John Mas wrote: > >> Hi, >> >> Could someone tell me how I should be using the SerialPortEvent? Am I >> meant to be waiting for data and then simply reading from the >> inputstream? If this is the case why no just block on an inputstream >> read? >> > > Polling for data is fine also. It really depends upon what you are > trying to do. For instance, if you require x bytes before reading, > you can start polling after data is available. If you read on the > same thread as your GUI and are waiting for data in a read, the > results may be less than desirable. > > Java programming is 'usually' event driven rather than polling based. Sounds good. I thought I would use this opportunity to provide a event based version of the TwoWaySerialComm example. Could you just validate it before I add it to the Wiki: package ajmas74.experimental; import gnu.io.CommPort; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; import gnu.io.SerialPortEvent; import gnu.io.SerialPortEventListener; import java.io.IOException; import java.io.InputStream; import java.io.OutputStream; /** * This version of the TwoWaySerialComm example makes use of the * SerialPortEventListener to avoid polling. * * @author ajmas * */ public class TwoWaySerialComm { public TwoWaySerialComm() { super(); } void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { CommPort commPort = portIdentifier.open(this.getClass().getName(),2000); if ( commPort instanceof SerialPort ) { SerialPort serialPort = (SerialPort) commPort; serialPort .setSerialPortParams (57600 ,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); (new Thread(new SerialWriter(out))).start(); serialPort.addEventListener(new SerialReader(in)); } else { System.out.println("Error: Only serial ports are handled by this example."); } } } /** * Handles the input coming from the serial port. A new line character * is treated as the end of a block in this example. */ public static class SerialReader implements SerialPortEventListener { private InputStream in; private byte[] buffer = new byte[1024]; public SerialReader ( InputStream in ) { this.in = in; } public void serialEvent(SerialPortEvent arg0) { int data; try { int len = 0; while ( ( data = in.read()) > -1 ) { if ( data != '\n' ) { break; } buffer[len++] = (byte) data; } System.out.print(new String(buffer,0,len)); } catch ( IOException e ) { e.printStackTrace(); System.exit(-1); } } } /** */ public static class SerialWriter implements Runnable { OutputStream out; public SerialWriter ( OutputStream out ) { this.out = out; } public void run () { try { int c = 0; while ( ( c = System.in.read()) > -1 ) { this.out.write(c); } } catch ( IOException e ) { e.printStackTrace(); System.exit(-1); } } } public static void main ( String[] args ) { try { (new TwoWaySerialComm()).connect("COM3"); } catch ( Exception e ) { e.printStackTrace(); } } } From lfarkas at lfarkas.org Tue Aug 19 07:32:59 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Tue, 19 Aug 2008 15:32:59 +0200 Subject: [Rxtx] JNI or CNI Message-ID: <48AACB8B.9060606@lfarkas.org> hi, what is the current recommended way to rxtx on linux JNI or it's better to use CNI? is the CNI version fully functional and the same level as the JNI? i currently try to make a rhel/centos/fedora rpm for rxtx but has many problems with the standard dir structure. yours. -- Levente "Si vis pacem para bellum!" From lfarkas at lfarkas.org Tue Aug 19 08:47:34 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Tue, 19 Aug 2008 16:47:34 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel Message-ID: <48AADD06.7040809@lfarkas.org> hi, newer or not so newer linux kernel do not contain the UTS_RELEASE so the current rxtx is not compile on the latest kernels. even if it's commented out in the cvs configure there are other places. i attcahed a patch which fix it (or at least doesn't cause error at non-debug build). ps. is there any plan to the new 2.1-8 release in the near future? there are many changes (at least the license change in all file and in this case create a diff is very difficult)? the latest release more then 2 years old:-( -- Levente "Si vis pacem para bellum!" -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-2.1-uts.patch Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080819/ab5d38ac/attachment-0025.pl From ajmas at sympatico.ca Tue Aug 19 16:21:53 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 19 Aug 2008 18:21:53 -0400 Subject: [Rxtx] Event based example Message-ID: <24735BFB-B088-4B84-8173-FE98DF63B12F@sympatico.ca> Hi, I have just posted an example of using SerialPortEventListener in the Wiki: http://rxtx.qbang.org/wiki/index.php/Event_Based_Two_Way_Communication If you see any issues please could you let me know, or makes the changes. Andre From Martin.Oberhuber at windriver.com Fri Aug 22 04:02:24 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 22 Aug 2008 12:02:24 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <48AADD06.7040809@lfarkas.org> References: <48AADD06.7040809@lfarkas.org> Message-ID: <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> Farkas, there are indeed efforts to get a new RXTX release out the door. Your experience as a package maintainer would likely be helpful during these efforts, since I'd think it makes sense to keep the patches minimal that you must make to have the source compile in your environment. What are the things that you find problematic, apart from the UTS thing that you have mentioned before? What is the timing that you have in mind for your package? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Farkas Levente > Sent: Tuesday, August 19, 2008 4:48 PM > To: rxtx at qbang.org > Subject: [Rxtx] UTS_RELEASE not defined in newer kernel > > hi, > newer or not so newer linux kernel do not contain the > UTS_RELEASE so the > current rxtx is not compile on the latest kernels. even if it's > commented out in the cvs configure there are other places. > i attcahed a patch which fix it (or at least doesn't cause error at > non-debug build). > > ps. is there any plan to the new 2.1-8 release in the near > future? there > are many changes (at least the license change in all file and in this > case create a diff is very difficult)? the latest release more then 2 > years old:-( > > -- > Levente "Si vis pacem para bellum!" > From lfarkas at lfarkas.org Fri Aug 22 04:36:26 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Fri, 22 Aug 2008 12:36:26 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> References: <48AADD06.7040809@lfarkas.org> <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> Message-ID: <48AE96AA.6090505@lfarkas.org> hi, the packages already build for fedora-9 and centos-5 and here: http://www.lfarkas.org/linux/packages/ what i've to patch, the UTS, the configure script, but it's already fixed in the cvs (in another way) and the loadlibrary. the reasons for last one can be found here: https://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_files_that_use_JNI after we test it i'd like to add these packages to fedora and epel main repository (that's why it's be useful a new release after 2 years:-) imho versions are cheap and why not just release 2.1-8? the real code changes are minimal and if something critical bug found still can release 2.1-9:-) ps. and would be better to use simple number for version like 2.1-7 rather then 2.1-7v2. Oberhuber, Martin wrote: > Farkas, > > there are indeed efforts to get a new RXTX release out the > door. Your experience as a package maintainer would likely > be helpful during these efforts, since I'd think it makes > sense to keep the patches minimal that you must make to > have the source compile in your environment. > > What are the things that you find problematic, apart from > the UTS thing that you have mentioned before? > > What is the timing that you have in mind for your package? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >> On Behalf Of Farkas Levente >> Sent: Tuesday, August 19, 2008 4:48 PM >> To: rxtx at qbang.org >> Subject: [Rxtx] UTS_RELEASE not defined in newer kernel >> >> hi, >> newer or not so newer linux kernel do not contain the >> UTS_RELEASE so the >> current rxtx is not compile on the latest kernels. even if it's >> commented out in the cvs configure there are other places. >> i attcahed a patch which fix it (or at least doesn't cause error at >> non-debug build). >> >> ps. is there any plan to the new 2.1-8 release in the near >> future? there >> are many changes (at least the license change in all file and in this >> case create a diff is very difficult)? the latest release more then 2 >> years old:-( >> >> -- >> Levente "Si vis pacem para bellum!" >> -- Levente "Si vis pacem para bellum!" From tjarvi at qbang.org Fri Aug 22 18:50:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Aug 2008 18:50:32 -0600 (MDT) Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <48AE96AA.6090505@lfarkas.org> References: <48AADD06.7040809@lfarkas.org> <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> <48AE96AA.6090505@lfarkas.org> Message-ID: Hi Farkas, The v2 was simply the second build - no code changes. We are comming out with a new release shortly. I would encourage working with distros as you are. The building of rxtx turns out to be a bottle neck in quick releases. We do want stable releases that work for a year or more but I would have no problems with quicker cycles on developing work. I would have no problem working with someone that did builds that receive less testing more often but they do have to come out for multiple platforms from this end. Thanks for the links. On Fri, 22 Aug 2008, Farkas Levente wrote: > hi, > the packages already build for fedora-9 and centos-5 and here: > http://www.lfarkas.org/linux/packages/ > what i've to patch, the UTS, the configure script, but it's already > fixed in the cvs (in another way) and the loadlibrary. the reasons for > last one can be found here: > https://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_files_that_use_JNI > after we test it i'd like to add these packages to fedora and epel main > repository (that's why it's be useful a new release after 2 years:-) > imho versions are cheap and why not just release 2.1-8? the real code > changes are minimal and if something critical bug found still can > release 2.1-9:-) > > ps. and would be better to use simple number for version like 2.1-7 > rather then 2.1-7v2. > > Oberhuber, Martin wrote: >> Farkas, >> >> there are indeed efforts to get a new RXTX release out the >> door. Your experience as a package maintainer would likely >> be helpful during these efforts, since I'd think it makes >> sense to keep the patches minimal that you must make to >> have the source compile in your environment. >> >> What are the things that you find problematic, apart from >> the UTS thing that you have mentioned before? >> >> What is the timing that you have in mind for your package? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >>> On Behalf Of Farkas Levente >>> Sent: Tuesday, August 19, 2008 4:48 PM >>> To: rxtx at qbang.org >>> Subject: [Rxtx] UTS_RELEASE not defined in newer kernel >>> >>> hi, >>> newer or not so newer linux kernel do not contain the >>> UTS_RELEASE so the >>> current rxtx is not compile on the latest kernels. even if it's >>> commented out in the cvs configure there are other places. >>> i attcahed a patch which fix it (or at least doesn't cause error at >>> non-debug build). >>> >>> ps. is there any plan to the new 2.1-8 release in the near >>> future? there >>> are many changes (at least the license change in all file and in this >>> case create a diff is very difficult)? the latest release more then 2 >>> years old:-( >>> >>> -- >>> Levente "Si vis pacem para bellum!" >>> > > > From andy at triera.net Sat Aug 23 15:17:44 2008 From: andy at triera.net (Andy Rozman) Date: Sat, 23 Aug 2008 21:17:44 +0000 Subject: [Rxtx] port not identified on FreeBSD In-Reply-To: References: Message-ID: <48B07E78.2030306@triera.net> Hi ! I have one small problem... I have started using FreeBSD in last few days and I have come accross a problem with rxtx on FreeBSD. I am using usb-to-serial converter, which is identified under FreeBSD without problem as ucom0, and creates link under /dev called ttyU0, which is correct way to be done under FreeBSD (if device would be unidentified it would be called ugen0 - as usb generic). Problem is that I say to rxtx to get my all serial ports this one is not among them. Which names are permissable under linux-like implementations? Which will be accepted as serial ports? Andy From tjarvi at qbang.org Sat Aug 23 13:57:45 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 23 Aug 2008 13:57:45 -0600 (MDT) Subject: [Rxtx] port not identified on FreeBSD In-Reply-To: <48B07E78.2030306@triera.net> References: <48B07E78.2030306@triera.net> Message-ID: On Sat, 23 Aug 2008, Andy Rozman wrote: > Hi ! > > I have one small problem... I have started using FreeBSD in last few > days and I have come accross a problem with rxtx on FreeBSD. > > I am using usb-to-serial converter, which is identified under FreeBSD > without problem as ucom0, and creates link under /dev called > ttyU0, which is correct way to be done under FreeBSD (if device would be > unidentified it would be called ugen0 - as usb generic). Problem is that > I say to rxtx to get my all serial ports this one is not among them. > Which names are permissable under linux-like implementations? Which will > be accepted as serial ports? > > Andy > Thanks Andy! We will add ttyU* to FreeBSD. For now you can use properties to enable the port. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting#How_does_rxtx_detect_ports.3F__Can_I_override_it.3F The fix: diff -u -r1.16.2.59 RXTXCommDriver.java --- RXTXCommDriver.java 18 Nov 2007 22:32:41 -0000 1.16.2.59 +++ RXTXCommDriver.java 23 Aug 2008 19:55:25 -0000 @@ -644,6 +644,7 @@ { String[] Temp = { "ttyd", //general purpose serial ports + "ttyU", //general purpose USB serial ports "cuaa", //dialout serial ports "ttyA", //Specialix SI/XIO dialin ports "cuaA", //Specialix SI/XIO dialout ports -- Trent Jarvi tjarvi at qbang.org From rick_knight at rlknight.com Mon Aug 4 13:25:10 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Mon, 04 Aug 2008 12:25:10 -0700 Subject: [Rxtx] Sun's Comm API? Message-ID: <48975796.4010600@rlknight.com> I have an application that requires the javax compatible version of RXTX and Sun's comm api. I've been able to download and extract the version of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api anywhere. Can someone tell me where I can find it? Or maybe send me a copy? Also, when I try to build RXTX, configure and make complete successfully but make install failes with this error libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 I've never come accross this error before. How can I get past it? Thanks, Rick From bboyes at systronix.com Mon Aug 4 19:10:01 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:10:01 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48975796.4010600@rlknight.com> References: <48975796.4010600@rlknight.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/cb9c6167/attachment-0041.html From bboyes at systronix.com Mon Aug 4 19:12:37 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:12:37 -0600 Subject: [Rxtx] Towards an RXTX release - CSR BT/USB chipset In-Reply-To: <488FB7E7.8000802@gmail.com> References: <460801A4097E3D4CA04CC64EE648584806C56CF0@ism-mail03.corp.ad.wrs.com> <13557-75390@sneakemail.com> <20980-23424@sneakemail.com> <488FB7E7.8000802@gmail.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/52236088/attachment-0041.html From tjarvi at qbang.org Mon Aug 4 19:42:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 19:42:21 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: On Mon, 4 Aug 2008, Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: > I have an application that requires the javax compatible > version of RXTX > and Sun's comm api. I've been able to download and extract > the version > of RXTX that I need (2.0-7pre2) but I can't find Sun's camm > api > anywhere. Can someone tell me where I can find it? Or maybe > send me a > > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm port > support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have just > a ZIP with only the .class JAR file - no source or docs), has a readme > with these comments: > > This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release.? The 2.0.3 release itself is > no longer distributed.? comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project.? The RxTx project (http://www.rxtx.org ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org) was opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support.? Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins.? Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > ? > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > I hope that is helpful! > It would be nice to work with Sun to resolve those longstanding issues. But it may not be practical unless the process goes as fast and painless as the grandfathering of commapi did. Another option may be the old kaffe extensions that moved to gnu classpathx. These don't have the native libraries but should provide the 2.0 interface and the javax.comm.properties mechansim for SPI. http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Mon Aug 4 20:23:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Mon, 04 Aug 2008 20:23:57 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4897B9BD.5070809@ergotech.com> Has there been any work/would it be possible, to layer a javacomm look-alike on top of the GNU code? The goal is not to move the javax code forward, but to emulate the "legacy" javax packages for people who still need this. Jim Trent Jarvi wrote: > On Mon, 4 Aug 2008, Bruce Boyes wrote: > >> At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible >> version of RXTX >> and Sun's comm api. I've been able to download and extract >> the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm >> api >> anywhere. Can someone tell me where I can find it? Or maybe >> send me a >> >> >> javaxcomm has had a sort of on-again off-again history. The windoze >> version has been languishing for years (literally) but there are newer >> versions for other OS's. >> >> We try to keep links on one of our help pages current: >> http://www.practicalembeddedjava.com/tools/javatools_list.html >> which gets you to here: >> http://java.sun.com/products/javacomm/ >> where it says in fact they no longer even support Windows and Mac: >> "Implementations of the API are currently available for Solaris SPARC, >> Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so >> someone could support it. But I guess that's part of the reason RXTX >> exists! >> >> So one of Sun's own products, SunSPOT, has to use RXTX to get comm port >> support. >> >> The version we use is 2.0 from 11/15/1998. I have posted it on our >> website, which is within the terms of the license agreement contained >> therein (as I understand it). >> >> The last version of javaxcomm for Windows, 2.0.3, (for which I have just >> a ZIP with only the .class JAR file - no source or docs), has a readme >> with these comments: >> >> This distribution contains the comm.jar file original part >> of the COMMAPI 2.0.3 release. The 2.0.3 release itself is >> no longer distributed. comm.jar, which contains the comm >> API java class files (eg. Sun's binary implementation of the >> interface classes), is being made available, unsupported, >> with no obligation to fix bugs, at the request of the RXTX >> project. The RxTx project (http://www.rxtx.org ), uses the >> comm.jar class files, but provides their own native library >> components to provide support for other platforms. >> >> The 2.0.3 comm.jar is being provided in this way because >> as of COMMAPI 3.x, the java binary implementation forked and >> became incompatible with the RxTx project's native code. >> Due to the lack of a clear business case, and to resource >> constraints, no additional resources are being >> provided to provide an alternative engineering solution >> at the time of writing. >> >> RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: >> >> Ultimately the COMMAPI would be better served if a Java >> Community Process JSR (http://www.jcp.org) was opened and >> the COMMAPI was rearchitected to provide a more pluggable >> framework to improve cross-platform support. Such an >> architecture would embody a better defined and better >> documented SPI interface, including a way for comm. ports >> to be revealed to the client application through the API >> via platform-aware plugins. Similarly, native code used >> to access comm port in general could be handled more >> flexibly using a plugin model, whereby on any platform, >> multiple native modules could be in use simultaneously. >> >> Since there are now various ways serial ports can be implemented >> and accessed, modular comm. port JNI native libraries would be >> of benefit insofar as removing the burden of over-generalization >> from any single native component, or inversely, by relieving the >> implicit constraint that comm. drivers be accessed only via a >> monolithic mechanism, such as the UNIX vnode interface. >> >> paul.klissner at sun.com >> 6/10/06 >> >> I hope that is helpful! >> > > It would be nice to work with Sun to resolve those longstanding issues. > But it may not be practical unless the process goes as fast and painless > as the grandfathering of commapi did. > > Another option may be the old kaffe extensions that moved to gnu > classpathx. These don't have the native libraries but should provide > the 2.0 interface and the javax.comm.properties mechansim for SPI. > > http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Mon Aug 4 21:09:15 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 21:09:15 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? Message-ID: Hi Jim, I will not step into the javax.comm namespace without Sun's explicite permission. I fully understand the pain point you are trying to address. In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm Linux) - which remains an integral part of rxtx. At the time it was a win for Sun and rxtx. The Sun commapi license is/was fairly clear that rxtx should not step into that namespace. It made sense as Sun was active in that space and rxtx may go into another namespace - it was an experiment in working with Sun. This may sound silly looking at something that happened almost 10 years ago. In a community of respect which Sun helped create, there is no question about what to do. I hope eventually Sun will step up and do a right thing too. I agree that this is hurting the API more than helping it. There are also questions about how to replace the API in the long term which includes HID support which isn't going well so far. Others that can't even look at Sun's javax.comm today and can look at Kaffe's contribution to classpathx can easily work around such restrictions. On Mon, 4 Aug 2008, Jim Redman wrote: > Has there been any work/would it be possible, to layer a javacomm > look-alike on top of the GNU code? > > The goal is not to move the javax code forward, but to emulate the > "legacy" javax packages for people who still need this. > > Jim > > Trent Jarvi wrote: >> >> It would be nice to work with Sun to resolve those longstanding issues. >> But it may not be practical unless the process goes as fast and painless >> as the grandfathering of commapi did. >> >> Another option may be the old kaffe extensions that moved to gnu >> classpathx. These don't have the native libraries but should provide >> the 2.0 interface and the javax.comm.properties mechansim for SPI. >> >> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From florianmanschwetus at gmx.de Tue Aug 5 05:04:46 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 13:04:46 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: References: <48971C1F.9020806@gmx.de> Message-ID: <489833CE.1040801@gmx.de> Just look at sendCommand in this method I have to place a Thread.sleep(20) after each byte send to get working. Even the event based receive doesn't work fine but this could be may stupidness. The specifikation document (it is on the last pages of the manual) for the beamer could be found on: http://www.optoma.co.uk/support.aspx Florian Manschwetus Trent Jarvi schrieb: > > Hi Florian > > Sorry for the top post in advance. I worry you may not see my answer > under all your code :) > > I have not received this email before. This is 500k of code which I > don't have time to read. I can spend about 5 min on each hobby email > and still get to work in the morning. I have a couple suggestions for > how to get an answer. > > First, cut out your comments and extra code so you can demonstrate the > question (I might even glance and see what is wrong then). Don't go for > a working final product. Isolate the problem using a simple program and > then ask with that as an example. If I did what you just did, I'd have > to post 3/4 of a million lines of code :) > > Second, join the rxtx mail-list and ask there. This will give you 100x > more eyes. I'll also read and try to follow. > > -- > taj > > > > On Mon, 4 Aug 2008, Florian Manschwetus wrote: > >> It could be that my university account is blocked by filters so >> resending from here. >> >> >> Topic is to control Optoma HD80 beamer using rs232 serial chat. >> This code is able to detect power state and switch the beamer on / off. >> connected is the beamer using a digitus usb 2.0 serial adapter with an >> FT232 USB-Serial adapter the systems architecture is amd64. >> >> Please take a look in the sendCommand routine i have to place theire >> those Thread.sleep to get it working. >> Now the question is this correct or is there a better way to get this >> working correctly? >> >> In the javadoc coming with the install i found this: >> setBaudBase >> >> public boolean setBaudBase(int BaudBase) >> throws UnsupportedCommOperationException, >> java.io.IOException >> >> Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 >> before using. >> >> could this explain the error? >> I attached my java source and the protocol description for the beamer >> (available on vendor website). >> >> thx, >> Florian Manschwetus >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: TestRS232.java Type: text/x-java Size: 9143 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0082.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0083.bin From michael.erskine at ketech.com Tue Aug 5 05:53:49 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Tue, 5 Aug 2008 12:53:49 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489833CE.1040801@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> > Just look at sendCommand in this method I have to place a > Thread.sleep(20) after each byte send to get working. Even the event > based receive doesn't work fine but this could be may stupidness. Hi Florian, Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. Regards, Michael Erskine. From florianmanschwetus at gmx.de Tue Aug 5 07:28:15 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:28:15 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> Message-ID: <4898556F.8000208@gmx.de> Michael Erskine schrieb: >> Just look at sendCommand in this method I have to place a >> Thread.sleep(20) after each byte send to get working. Even the event >> based receive doesn't work fine but this could be may stupidness. > > Hi Florian, > > Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. > > Regards, > Michael Erskine. > Ok, sounds fine for the receiving problem. But why i have to wait after each byte when sending a command squence? (the for loop in send command) Florian > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/284f350c/attachment-0040.bin From florianmanschwetus at gmx.de Tue Aug 5 07:44:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:44:14 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <4898592E.2020908@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >>> Just look at sendCommand in this method I have to place a >>> Thread.sleep(20) after each byte send to get working. Even the event >>> based receive doesn't work fine but this could be may stupidness. >> >> Hi Florian, >> >> Yes, naturally you'll have to wait for a response from the other end. >> Why not wait for notification from the event thread perhaps using a >> BlockingDeque rather than your LinkedList. Generally I >> try to decouple all input and output streams: in your case your >> application is operating synchronously like the "expect" program >> (http://expect.nist.gov/) so waits (or timeouts) will need to be >> factored in. >> >> Regards, >> Michael Erskine. >> > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) > > Florian Furthermore there is this basic baud with this confusing javadoc entry: public boolean setBaudBase(int BaudBase) throws UnsupportedCommOperationException, java.io.IOException Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 before using. maybe this could explain something Florian >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/006c7425/attachment-0040.bin From jredman at ergotech.com Tue Aug 5 09:13:36 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 05 Aug 2008 09:13:36 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: Message-ID: <48986E20.3060104@ergotech.com> Trent, So two issues: 1) Technically I'm still not sure how easy/practical a layer would be. The problems are always classes like listeners, and wrapping returns of gnu.io classes. I really see it as a "delegate" type of concept. Any thoughts or ideas of the practicality of this approach? The idea is not to modify RXTX. 2) Javax. The javax namespace does seem to be in widespread use outside of Sun (the same is true for the java namespace). The classpath extensions, or some other location, should be interested in a JavaComm implementation even if it does have dependencies on RXTX. Would you have any philosophical objection to an approach like that? Of course, I suspect it might be better if someone with that authority at Sun would admit that the javax namespace is already in the wild and that there is no problem with it being used within RXTX. Jim Trent Jarvi wrote: > Hi Jim, > > I will not step into the javax.comm namespace without Sun's explicite > permission. I fully understand the pain point you are trying to address. > > In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm > Linux) - which remains an integral part of rxtx. At the time it was a win for > Sun and rxtx. > > The Sun commapi license is/was fairly clear that rxtx should not step into that > namespace. It made sense as Sun was active in that space and rxtx may go into > another namespace - it was an experiment in working with Sun. > > This may sound silly looking at something that happened almost 10 years ago. > In a community of respect which Sun helped create, there is no question about > what to do. I hope eventually Sun will step up and do a right thing too. > > I agree that this is hurting the API more than helping it. There are also > questions about how to replace the API in the long term which includes HID > support which isn't going well so far. > > Others that can't even look at Sun's javax.comm today and can look at Kaffe's > contribution to classpathx can easily work around such restrictions. > > On Mon, 4 Aug 2008, Jim Redman wrote: > >> Has there been any work/would it be possible, to layer a javacomm >> look-alike on top of the GNU code? >> >> The goal is not to move the javax code forward, but to emulate the >> "legacy" javax packages for people who still need this. >> >> Jim >> >> Trent Jarvi wrote: >>> It would be nice to work with Sun to resolve those longstanding issues. >>> But it may not be practical unless the process goes as fast and painless >>> as the grandfathering of commapi did. >>> >>> Another option may be the old kaffe extensions that moved to gnu >>> classpathx. These don't have the native libraries but should provide >>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>> >>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From sandeep at genevasoftech.com Tue Aug 5 11:18:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Tue, 05 Aug 2008 22:48:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <48988B6C.5080409@genevasoftech.com> Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. *-- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/ad20f1cb/attachment-0040.html From Martin.Oberhuber at windriver.com Tue Aug 5 13:30:17 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Tue, 5 Aug 2008 21:30:17 +0200 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Sandeep, shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on Sol7 but I've successfully run it on Sol9 and Sol10. Or is your request really about a native 64bit variant? I'm afraid that then you're out of luck since I think that quite a bit of RXTX is not yet ready for 64 bit. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Sandeep Kumar K Sent: Tuesday, August 05, 2008 7:19 PM To: rxtx at qbang.org Subject: [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so for Solaris 9 Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. -- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/81b7f988/attachment-0040.html From tjarvi at qbang.org Tue Aug 5 22:38:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 22:38:34 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 5 Aug 2008, Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built > on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid that > then > you're out of luck since I think that quite a bit of RXTX is not yet > ready > for 64 bit. > While rxtx-2.1-7 probably has problems, The CVS code should be OK for 64 bit Solaris. If it isn't, let me know and I'll find which patch is missing. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Aug 5 23:13:00 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 23:13:00 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48986E20.3060104@ergotech.com> References: <48986E20.3060104@ergotech.com> Message-ID: On Tue, 5 Aug 2008, Jim Redman wrote: > Trent, > > So two issues: > > 1) Technically I'm still not sure how easy/practical a layer would be. The > problems are always classes like listeners, and wrapping returns of gnu.io > classes. I really see it as a "delegate" type of concept. Any thoughts or > ideas of the practicality of this approach? The idea is not to modify RXTX. I have not put too much thought into this. I assume you want what rxtx 2.0 provided to tie into javax.comm implementations. More classes could be added to rxtx 2.1-7 for SPI support. Maintaining rxtx-2.0 could also be handed to someone if they like. > > 2) Javax. The javax namespace does seem to be in widespread use outside of > Sun (the same is true for the java namespace). The classpath extensions, or > some other location, should be interested in a JavaComm implementation even > if it does have dependencies on RXTX. Would you have any philosophical > objection to an approach like that? > No problems. Classpathx would be a possible place to do it. I'd suggest thinking twice about what this involves in practical terms. You would be wanting to revive the 2.0 API while Sun is at 3.0 and grandfathering the JSR. This undermines the main reason (established api) for using the javax.comm namespace and does not leave such a project in a good position. The only win I see here is maintaining support for applications that can't migrate namespaces. Not that that isn't important. At some point it is going to be less work to just edit the bytecode :) Such a javax.comm effort would also be signing up new projects that decided to use the work up for concerns they probably will not understand or expect. That probably isn't a good path to facilitate for new projects at this time. We will put a good faith effort to work well with others but keep in mind the project has limited bandwidth for such efforts. > Of course, I suspect it might be better if someone with that authority at Sun > would admit that the javax namespace is already in the wild and that there is > no problem with it being used within RXTX. > > Jim > > Trent Jarvi wrote: >> Hi Jim, >> >> I will not step into the javax.comm namespace without Sun's explicite >> permission. I fully understand the pain point you are trying to address. >> >> In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java >> Comm Linux) - which remains an integral part of rxtx. At the time it was a >> win for Sun and rxtx. >> >> The Sun commapi license is/was fairly clear that rxtx should not step into >> that namespace. It made sense as Sun was active in that space and rxtx may >> go into another namespace - it was an experiment in working with Sun. >> >> This may sound silly looking at something that happened almost 10 years >> ago. In a community of respect which Sun helped create, there is no >> question about what to do. I hope eventually Sun will step up and do a >> right thing too. >> >> I agree that this is hurting the API more than helping it. There are also >> questions about how to replace the API in the long term which includes HID >> support which isn't going well so far. >> >> Others that can't even look at Sun's javax.comm today and can look at >> Kaffe's contribution to classpathx can easily work around such >> restrictions. >> >> On Mon, 4 Aug 2008, Jim Redman wrote: >> >>> Has there been any work/would it be possible, to layer a javacomm >>> look-alike on top of the GNU code? >>> >>> The goal is not to move the javax code forward, but to emulate the >>> "legacy" javax packages for people who still need this. >>> >>> Jim >>> >>> Trent Jarvi wrote: >>>> It would be nice to work with Sun to resolve those longstanding issues. >>>> But it may not be practical unless the process goes as fast and painless >>>> as the grandfathering of commapi did. >>>> >>>> Another option may be the old kaffe extensions that moved to gnu >>>> classpathx. These don't have the native libraries but should provide >>>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>>> >>>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From sandeep at genevasoftech.com Wed Aug 6 00:03:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Wed, 06 Aug 2008 11:33:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: <48993EB8.30107@genevasoftech.com> Thank you Mr. Martin for your suggestion. The native file which is given in rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am getting the following error . Any suggestions to solve this issue. I am using Solaris SPARC 64 bit machine. ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) thrown while loading gnu.io.RXTXCommDriver Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(Unknown Source) at java.lang.ClassLoader.loadLibrary(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) at com.ReadFromModem.main(ReadFromModem.java:84) * * *Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid > that then > you're out of luck since I think that quite a bit of RXTX is not yet ready > for 64 bit. > > Cheers, > -- > *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > ------------------------------------------------------------------------ > *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On > Behalf Of *Sandeep Kumar K > *Sent:* Tuesday, August 05, 2008 7:19 PM > *To:* rxtx at qbang.org > *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so > for Solaris 9 > > Hi, > > Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 > bit machine. The librxtxSerial.so given in website is for Solaris 8. > > *-- > > Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/1e920343/attachment-0040.html From tjarvi at qbang.org Wed Aug 6 00:21:42 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 00:21:42 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <48993EB8.30107@genevasoftech.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> <48993EB8.30107@genevasoftech.com> Message-ID: Hi Sandeep You may be out of luck unless you can compile the 2.1 src in CVS (requires gnu make and gcc). But you could try the ToyBox(R)(TM) which is a collection of WiLdLy untested cross compiled 2.1-7 binaries covering everything from the ibm z series to embeded arm/ppc. To give an idea how poorly these are tested, I don't even know if z series machines have a serial port. ftp://www.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Solaris They should at least match the binary types. Actually, I think if you use the rxtx jar from CVS with that file, it should 'work' as the fix for 64 bits was in java not the native code. You could just cd rxtx*/src; javac *.java then jar -cf RXTXcomm.jar `find -name \*.class` to create the hybrid which will complain about version information a bit. On Wed, 6 Aug 2008, Sandeep Kumar K wrote: > Thank you Mr. Martin for your suggestion. The native file which is given in > rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am > getting the following error . > Any suggestions to solve this issue. > I am using Solaris SPARC 64 bit machine. > > ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar > java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 > (Possible cause: architecture word > width mismatch) thrown while loading gnu.io.RXTXCommDriver > Exception in thread "main" java.lang.UnsatisfiedLinkError: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF > class: ELFCLASS64 (Possible cause: > architecture word width mismatch) > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(Unknown Source) > at java.lang.ClassLoader.loadLibrary(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > at com.ReadFromModem.main(ReadFromModem.java:84) > > * > * > > *Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > > > Oberhuber, Martin wrote: >> Sandeep, >> shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse >> variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on >> Sol7 but I've successfully run it on Sol9 and Sol10. >> Or is your request really about a native 64bit variant? I'm afraid that >> then >> you're out of luck since I think that quite a bit of RXTX is not yet ready >> for 64 bit. >> Cheers, >> -- >> *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> ------------------------------------------------------------------------ >> *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On >> Behalf Of *Sandeep Kumar K >> *Sent:* Tuesday, August 05, 2008 7:19 PM >> *To:* rxtx at qbang.org >> *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so >> for Solaris 9 >> >> Hi, >> >> Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 >> bit machine. The librxtxSerial.so given in website is for Solaris 8. >> >> *-- >> Thanks & Regards >> >> Sandeep Kumar K >> Sr. Software Engineer >> Geneva Software Technologies >> Whitefield, Bangalore >> Mob : 9880193454* >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> From michael.erskine at ketech.com Wed Aug 6 01:39:28 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 6 Aug 2008 08:39:28 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Florian Manschwetus wrote: > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) Hi Florian, I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. Regards, Michael Erskine. From florianmanschwetus at gmx.de Wed Aug 6 02:53:16 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 06 Aug 2008 10:53:16 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Message-ID: <4899667C.6010706@gmx.de> Michael Erskine schrieb: > Florian Manschwetus wrote: >> Ok, sounds fine for the receiving problem. >> But why i have to wait after each byte when sending a command squence? >> (the for loop in send command) > > Hi Florian, > I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. > > Regards, > Michael Erskine. > correct with a terminal on the other end it works, my idea was that this basic baud has some influence. Could some one explain what it is for? Florian > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/c2b4fa84/attachment-0040.bin From rick_knight at rlknight.com Wed Aug 6 13:01:07 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:01:07 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F4F3.3020707@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > I have an application (Readerware) that uses RXTX with Javax to access the serial port. This used to work fine under previous Linux' and Java, but something has changed, I assume with Java itself , that is causing the application to fail with a link error. The application is not able to find librxtxSerialParallel.so. RXTX supplies librxtxSerial.so and librxtxParallel.so, but not librxtxSerialParallel.so. Where can I get librxtxSerialParallel.so, or do I need it? Is something else causing the lib to not be found? Thanks, Rick Knight From rick_knight at rlknight.com Wed Aug 6 13:17:55 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:17:55 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F8E3.5060400@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Thanks for the reply. The developer of the app I'm trying to use (Readerware) has sent me a copy of the comm.api and I've copied the library (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar into the proper places. When I try to run the application, I get this error... Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: /usr/lib/libSolarisSerialParallel.so: /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not little-endian (Possible cause: endianness mismatch) Caught java.lang.UnsatisfiedLinkError: com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I while loading driver com.sun.comm.SolarisDriver Is there a way around this error? Thanks again, Rick Knight From jlar310 at gmail.com Wed Aug 6 13:37:42 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 14:37:42 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899F8E3.5060400@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > The developer of the app I'm trying to use (Readerware) has sent me a > copy of the comm.api and I've copied the library > (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar > into the proper places. When I try to run the application, I get this > error... > > Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: > /usr/lib/libSolarisSerialParallel.so: > /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not > little-endian (Possible cause: endianness mismatch) > Caught java.lang.UnsatisfiedLinkError: > com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I > > while loading driver com.sun.comm.SolarisDriver > > Is there a way around this error? What host OS are you running? From your original post it looks like 32 bit Linux. The libSolarisSerialParallel.so file is for Sun Solaris and will vary depending on the underlying hardware architecture as well. Sorry for the double post Rick, but I failed to send this to the list the first time... -- Jeff From rick_knight at rlknight.com Wed Aug 6 13:44:29 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:44:29 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: <4899FF1D.9030504@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > > >> The developer of the app I'm trying to use (Readerware) has sent me a >> copy of the comm.api and I've copied the library >> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >> into the proper places. When I try to run the application, I get this >> error... >> >> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >> /usr/lib/libSolarisSerialParallel.so: >> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >> little-endian (Possible cause: endianness mismatch) >> Caught java.lang.UnsatisfiedLinkError: >> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >> >> while loading driver com.sun.comm.SolarisDriver >> >> Is there a way around this error? >> > > What host OS are you running? From your original post it looks like 32 > bit Linux. > > The libSolarisSerialParallel.so file is for Sun Solaris and will vary > depending on the underlying hardware architecture as well. > > I'm running Kubuntu Linux (debian based). It's 32 bit. Rick Knight From jlar310 at gmail.com Wed Aug 6 15:33:23 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 16:33:23 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > I don't think Sun did binary libraries for Linux in the 2.0 version. Can someone with more historical experience than I confirm that? I recently tried to port a Comm API application from Solaris sparc to Linux x86 and likewise could not get my hands on the binary libraries. I eventually just re-wrote the code to use the gnu namespace packages and rxtx 2.1. What I don't understand is why your application vendor does not provide everything you need to run their software. FYI: I have librxtxParallel.so and librxtxSerial.so installed at JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is /usr/java/default which is actually a softlink to /usr/java/jre1.6.0_05. -- Jeff From defiantlew at yahoo.com.au Wed Aug 6 16:29:33 2008 From: defiantlew at yahoo.com.au (Lew L) Date: Thu, 7 Aug 2008 08:29:33 +1000 Subject: [Rxtx] Sun's Comm API Documentation References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> Message-ID: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> As a matter of interest is the Sun Comm API documentation available somewhere? I have tried the Sun site but it seems to have been removed. Unless I have missed the documentation for RXTX? I javadocced the RXTX source but information (to me) is minimal. Somewhere I got the impression that the Sun Comm API docs is, or was, compatible with RXTX, what is the best docs to use in conjuntion with RXTX and where may the be available? Cheers Lew From rick_knight at rlknight.com Wed Aug 6 17:18:33 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:18:33 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A3149.4050306@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff I'm not sure if I posted this here or not, but when I try to build RXTX from source I get this install error... make all-am make[1]: Entering directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' make[1]: Nothing to be done for `all-am'. make[1]: Leaving directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 Can you tell me how to get past this error and get RXTX built and installed? Thanks, Rick From bboyes at systronix.com Wed Aug 6 17:40:12 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Wed, 06 Aug 2008 17:40:12 -0600 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: At 16:29 08/06/2008, Lew L wrote: >As a matter of interest is the Sun Comm API documentation available >somewhere? I have tried the Sun site but it seems to have been removed. It's in the file we have posted, link in prev email (sorry, in a huge hurry right now). Javadocs definitely there. >Unless I have missed the documentation for RXTX? I javadocced the RXTX >source but information (to me) is minimal. >Somewhere I got the impression that the Sun Comm API docs is, or was, >compatible with RXTX, what is the best docs to use in conjuntion with RXTX >and where may the be available? Yeah, this is one of my concerns/beefs. There is little documentation for RXTX and it isn't just the same as javaxcomm. I would be willing to help out writing docs for RXTX! Yes really... esp if we can fix the Bluetooth issues. best regards Bruce >Cheers >Lew > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx ------- WWW.SYSTRONIX.COM ---------- Real embedded Java and much more +1-801-534-1017 Salt Lake City, USA From rick_knight at rlknight.com Wed Aug 6 17:54:08 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:54:08 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A39A0.2090309@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff, I would like for my vendor to switch to rxtx 2.1. It would make things much easier for me. I'm not sure why he's still using the javax compatible code. He's a small operation. Re-writing the code to use gnu namespace sounds like a major overhaul. Was it? Thanks, Rick From tjarvi at qbang.org Wed Aug 6 21:35:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:35:12 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: >> >>> Jeff wrote: >>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>>> >>>> >>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things > much easier for me. I'm not sure why he's still using the javax > compatible code. He's a small operation. Re-writing the code to use gnu > namespace sounds like a major overhaul. Was it? > Hi Jeff, The changes are fairly mechanical. Imports need to change and any explicite use of the namespace needs to change such as catching an exception. The following script was made for maintaining rxtx 2.0 but can apply to other needs. It is in the contrib dir with rxtx source. #!/bin/sh # Don't use! :) # # Sat, 03 May 2003 16:45:08 Modifications from J?rg Weule # Create a ed-cmd for the change of one pattern # case $1 in gnu) X=g/javax_comm/s+javax_comm+gnu_io+g ;; javax) X=g/gnu_io/s+gnu_io+javax_comm+g ;; *) echo;echo;echo From the top rxtx directory run;echo;echo -e \\t./ChangePackage.sh gnu;echo -e \\t\\tor;echo -e \\t./ChangePackage.sh javax;echo;echo; exit 0 ;; esac # # ed will be used to keep the owner and mode of the files unchanged. # We have run the ed-script for the characters '.' '/' as well. # "tr _ $D" do the change. # find . -type f -a -print | grep -v $0 | (while read F ; do ( echo $X; echo $X| tr _ /; echo $X| tr _ .; echo w; echo q ) | ed $F 2>&1 >/dev/null done ) # # Now we do little changes at the Makefiles. Hope that all we need. # find . -name Makefile\* -a -print | (while read F ; do cat < References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: On Thu, 7 Aug 2008, Lew L wrote: > As a matter of interest is the Sun Comm API documentation available > somewhere? I have tried the Sun site but it seems to have been removed. > > Unless I have missed the documentation for RXTX? I javadocced the RXTX > source but information (to me) is minimal. > Somewhere I got the impression that the Sun Comm API docs is, or was, > compatible with RXTX, what is the best docs to use in conjuntion with RXTX > and where may the be available? > Hi Lew, The documentation on Sun's website is accurate. The changes that are problematic in 3.0 are on the backside which rxtx used to plug into. http://java.sun.com/products/javacomm/reference/api/index.html CommPortIdentifier may have some minor differences (judging by the authors notes). -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Aug 6 21:46:08 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:46:08 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > If javax.comm.properties is properly installed and you are using a 2.0 version of Sun's commapi with rxtx 2.0, you should not see the library attempt to load libSolarisSerialParallel.so. Sun CommAPI 3.0 will not work with any version of rxtx as it is hard coded to use the shared library. See the INSTALL file with rxtx-2.0 source for more help with the properties file. -- Trent Jarvi tjarvi at qbang.org From jlar310 at gmail.com Thu Aug 7 06:32:06 2008 From: jlar310 at gmail.com (Jeff) Date: Thu, 7 Aug 2008 07:32:06 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > Jeff wrote: >> >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >> wrote: >> >>> >>> Jeff wrote: >>> >>>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>> wrote: >>>> >>>> >>>> >>>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things much > easier for me. I'm not sure why he's still using the javax compatible code. > He's a small operation. Re-writing the code to use gnu namespace sounds like > a major overhaul. Was it? I found it quite easy. In fact, in order to accommodate the transition, I actually separated all of the code that deals directly with the Comm API or RXTX into a helper class. The helper class was then coded to use reflection to determine which library was available and then instantiate the necessary objects. No direct imports of either library are used. The main application just needs to get it's hands on the IO streams and need not deal directly with the libraries. Other programs may not be so simple... But this doesn't really help you unless your vendor forks over the source code... -- Jeff From rick_knight at rlknight.com Thu Aug 7 09:47:12 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Thu, 07 Aug 2008 08:47:12 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: <489B1900.10108@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >>> wrote: >>> >>> >>>> Jeff wrote: >>>> >>>> >>>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>>> copy of the comm.api and I've copied the library >>>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>>> into the proper places. When I try to run the application, I get this >>>>>> error... >>>>>> >>>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>>> /usr/lib/libSolarisSerialParallel.so: >>>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>>> little-endian (Possible cause: endianness mismatch) >>>>>> Caught java.lang.UnsatisfiedLinkError: >>>>>> >>>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>>> >>>>>> while loading driver com.sun.comm.SolarisDriver >>>>>> >>>>>> Is there a way around this error? >>>>>> >>>>>> >>>>>> >>>>> What host OS are you running? From your original post it looks like 32 >>>>> bit Linux. >>>>> >>>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>>> depending on the underlying hardware architecture as well. >>>>> >>>>> >>>>> >>>>> >>>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>>> >>>> >>>> >>> I don't think Sun did binary libraries for Linux in the 2.0 version. >>> Can someone with more historical experience than I confirm that? >>> >>> I recently tried to port a Comm API application from Solaris sparc to >>> Linux x86 and likewise could not get my hands on the binary libraries. >>> I eventually just re-wrote the code to use the gnu namespace packages >>> and rxtx 2.1. >>> >>> What I don't understand is why your application vendor does not >>> provide everything you need to run their software. >>> >>> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >>> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >>> /usr/java/default which is actually a softlink to >>> /usr/java/jre1.6.0_05. >>> >>> >>> >> Jeff, >> >> I would like for my vendor to switch to rxtx 2.1. It would make things much >> easier for me. I'm not sure why he's still using the javax compatible code. >> He's a small operation. Re-writing the code to use gnu namespace sounds like >> a major overhaul. Was it? >> > > I found it quite easy. In fact, in order to accommodate the > transition, I actually separated all of the code that deals directly > with the Comm API or RXTX into a helper class. The helper class was > then coded to use reflection to determine which library was available > and then instantiate the necessary objects. No direct imports of > either library are used. The main application just needs to get it's > hands on the IO streams and need not deal directly with the libraries. > Other programs may not be so simple... > > But this doesn't really help you unless your vendor forks over the > source code... > > Jeff, This may not help me directly, but I'm going to forward this thread to the vendor. I think he'll be open to making things work. Thanks again, Rick Knight From agusmunioz at gmail.com Thu Aug 7 16:39:51 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Thu, 7 Aug 2008 19:39:51 -0300 Subject: [Rxtx] How to send ack? Message-ID: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Hi, I'm still learning about serial communication and I have some doubts. I've got this question about how to do the following thing in rxtx. I have this hardware that connect to a PC using a serial port. These hardware receives data from a telephone line, proccess it, and then send it forward to the serial port. I've used a program named wincomm that shows what information is send it through the serial port and I have the nex behaviour: The hardware has a buffer where all data is stored, that cannot be sent it through the seria port. The program reads the first data send it by the hardware, and keep reading the same data always. There is a button in the application that says enable Ack, and when I click, then the hardware start to send all the stored information, and all the information is shown. I write a class, using rxtx that reads the serial port, and the same thing happens, it remains reading the same (first) data all the time. And I thing something like the enable Ack I'm missing. How can I do this enable Ack from my java code using rxtx? Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080807/e0a0f9a1/attachment-0038.html From ajmas at sympatico.ca Thu Aug 7 18:26:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 7 Aug 2008 20:26:41 -0400 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: <4BF42297-81E2-4BB8-A89F-1D43588379AE@sympatico.ca> On 6-Aug-08, at 19:40 , Bruce Boyes wrote: >> Unless I have missed the documentation for RXTX? I javadocced the >> RXTX >> source but information (to me) is minimal. >> Somewhere I got the impression that the Sun Comm API docs is, or was, >> compatible with RXTX, what is the best docs to use in conjuntion >> with RXTX >> and where may the be available? > > Yeah, this is one of my concerns/beefs. There is little documentation > for RXTX and it isn't just the same as javaxcomm. > > I would be willing to help out writing docs for RXTX! Yes really... > esp if we can fix the Bluetooth issues. If you want to contribute documentation then the best place to do that is the wiki. If there is anything missing or that could be improved on then please do so. If there are any points that you would like to see improved, for which you don't have the knowledge then ask on the mailing list for a volunteer. Andre From florianmanschwetus at gmx.de Fri Aug 8 03:04:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Fri, 08 Aug 2008 11:04:14 +0200 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Message-ID: <489C0C0E.2020401@gmx.de> Agustin Mu?oz schrieb: > Hi, I'm still learning about serial communication and I have some > doubts. I've got this question about how to do the following thing in rxtx. > I have this hardware that connect to a PC using a serial port. These > hardware receives data from a telephone line, proccess it, and then send > it forward to the serial port. I've used a program named wincomm that > shows what information is send it through the serial port and I have the > nex behaviour: > > The hardware has a buffer where all data is stored, that cannot be sent > it through the seria port. > The program reads the first data send it by the hardware, and keep > reading the same data always. > There is a button in the application that says enable Ack, and when I > click, then the hardware start to send all the stored information, and > all the information is shown. > > I write a class, using rxtx that reads the serial port, and the same > thing happens, it remains reading the same (first) data all the time. > And I thing something like the enable Ack I'm missing. > How can I do this enable Ack from my java code using rxtx? Afaik, a look at man ascii reveals: Okt Dez Hex Char 006 6 06 ACK So, i hope this will do the job: send(6); florian > > Thanks in advance > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/5b4965f8/attachment-0038.bin From agusmunioz at gmail.com Fri Aug 8 16:31:00 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 19:31:00 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <489C0C0E.2020401@gmx.de> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> Message-ID: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Hi Florian, thanks for the answer. By send(6) you mean to get the port OutputStream and write a 6? I try that but it didn't work. Any suggestion? Thanks On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < florianmanschwetus at gmx.de> wrote: > Agustin Mu?oz schrieb: > > Hi, I'm still learning about serial communication and I have some doubts. >> I've got this question about how to do the following thing in rxtx. >> I have this hardware that connect to a PC using a serial port. These >> hardware receives data from a telephone line, proccess it, and then send it >> forward to the serial port. I've used a program named wincomm that shows >> what information is send it through the serial port and I have the nex >> behaviour: >> >> The hardware has a buffer where all data is stored, that cannot be sent >> it through the seria port. >> The program reads the first data send it by the hardware, and keep reading >> the same data always. >> There is a button in the application that says enable Ack, and when I >> click, then the hardware start to send all the stored information, and all >> the information is shown. >> >> I write a class, using rxtx that reads the serial port, and the same thing >> happens, it remains reading the same (first) data all the time. And I thing >> something like the enable Ack I'm missing. >> How can I do this enable Ack from my java code using rxtx? >> > Afaik, a look at man ascii reveals: > Okt Dez Hex Char > 006 6 06 ACK > So, i hope this will do the job: > send(6); > > florian > >> >> Thanks in advance >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/7f3fba42/attachment-0037.html From agusmunioz at gmail.com Fri Aug 8 18:39:27 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 21:39:27 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Message-ID: <988288430808081739x7f9e7889id82591d5a9e2b4f6@mail.gmail.com> Ok, Florian, it works!! my problem was that I've been sending, through the OutputStream, the bytes of 6 as a string: out.write("6".getBytes()); but then I realized that you can write an int on an OuptuStream, so I tried that and It works: out.write(6); Thank you for the guidance!! On Fri, Aug 8, 2008 at 7:31 PM, Agustin Mu?oz wrote: > Hi Florian, thanks for the answer. By send(6) you mean to get the port > OutputStream and write a 6? > > I try that but it didn't work. > > Any suggestion? > > Thanks > > > On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < > florianmanschwetus at gmx.de> wrote: > >> Agustin Mu?oz schrieb: >> >> Hi, I'm still learning about serial communication and I have some doubts. >>> I've got this question about how to do the following thing in rxtx. >>> I have this hardware that connect to a PC using a serial port. These >>> hardware receives data from a telephone line, proccess it, and then send it >>> forward to the serial port. I've used a program named wincomm that shows >>> what information is send it through the serial port and I have the nex >>> behaviour: >>> >>> The hardware has a buffer where all data is stored, that cannot be sent >>> it through the seria port. >>> The program reads the first data send it by the hardware, and keep >>> reading the same data always. >>> There is a button in the application that says enable Ack, and when I >>> click, then the hardware start to send all the stored information, and all >>> the information is shown. >>> >>> I write a class, using rxtx that reads the serial port, and the same >>> thing happens, it remains reading the same (first) data all the time. And I >>> thing something like the enable Ack I'm missing. >>> How can I do this enable Ack from my java code using rxtx? >>> >> Afaik, a look at man ascii reveals: >> Okt Dez Hex Char >> 006 6 06 ACK >> So, i hope this will do the job: >> send(6); >> >> florian >> >>> >>> Thanks in advance >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/b918ab3d/attachment-0037.html From florianmanschwetus at gmx.de Sat Aug 9 00:45:43 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Sat, 09 Aug 2008 08:45:43 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4899667C.6010706@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> Message-ID: <489D3D17.9090209@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >> Florian Manschwetus wrote: >>> Ok, sounds fine for the receiving problem. >>> But why i have to wait after each byte when sending a command squence? >>> (the for loop in send command) >> >> Hi Florian, >> I'd imagine you probably don't! You could send all bytes in one go and >> RXTX would send them. The problem is most probably the other end: >> perhaps it has a really small buffer, some non-standard UART, or a >> crazy timing issue. If you attach a terminal to your output and send >> all the bytes of a command in one go they should appear no problem. >> >> Regards, >> Michael Erskine. >> > correct with a terminal on the other end it works, my idea was that this > basic baud has some influence. Could some one explain what it is for? > > Florian To make it more clear, my problem is that i can't use: outputStream.write(byte[]); => Beamer doesn't understand the sequence. (mostly no answer when he answers then *001) when i use this construct instead: for (int i = 0; i < command.length; i++) { this.outputStream.write(command[i]); try { Thread.sleep(25); } catch (InterruptedException e) { // TODO Auto-generated catch block e.printStackTrace(); } } it works nearly reliable. So what could it be? This Basic Baud is what exactly? Florian -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080809/692304ee/attachment-0037.bin From tjarvi at qbang.org Sat Aug 9 16:37:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Aug 2008 16:37:19 -0600 (MDT) Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489D3D17.9090209@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> <489D3D17.9090209@gmx.de> Message-ID: On Sat, 9 Aug 2008, Florian Manschwetus wrote: > Florian Manschwetus schrieb: >> Michael Erskine schrieb: >>> Florian Manschwetus wrote: >>>> Ok, sounds fine for the receiving problem. >>>> But why i have to wait after each byte when sending a command squence? >>>> (the for loop in send command) >>> >>> Hi Florian, >>> I'd imagine you probably don't! You could send all bytes in one go and >>> RXTX would send them. The problem is most probably the other end: perhaps >>> it has a really small buffer, some non-standard UART, or a crazy timing >>> issue. If you attach a terminal to your output and send all the bytes of a >>> command in one go they should appear no problem. >>> >>> Regards, >>> Michael Erskine. >>> >> correct with a terminal on the other end it works, my idea was that this >> basic baud has some influence. Could some one explain what it is for? >> >> Florian > To make it more clear, > my problem is that i can't use: > outputStream.write(byte[]); > => Beamer doesn't understand the sequence. (mostly no answer when he answers > then *001) > > when i use this construct instead: > > for (int i = 0; i < command.length; i++) { > this.outputStream.write(command[i]); > try { > Thread.sleep(25); > } catch (InterruptedException e) { > // TODO Auto-generated catch block > e.printStackTrace(); > } > } > > it works nearly reliable. > > So what could it be? This Basic Baud is what exactly? > I suspect you are using the 'moon protocol' and don't know it. RXTX enables this by default. The buffer on the other end is first in first out while reading. If the buffer is full, the bits are hand carried to the moon and burried. Then if the other side reads a couple bytes, two more bytes go into the buffer followed by more moon protocol. The resulting array of bytes the other side reads may appear to be scrambled until you go to the moon, get the bits and insert them in the right place. Flow control can prevent the default moon protocol and throttles the communiation by almost writing a byte at a time as need be. Hardware flow control is preferable but software flow control should also work. Read and write can appear to hang if the other side is not connected. This is why we don't enable them all the time. If you can't use flow control, you have to take care with the moon protocol and give the other side time to read. That is what your slower version of write is doing. -- Trent Jarvi tjarvi at qbang.org From rxtx at allenjb.me.uk Mon Aug 11 08:06:36 2008 From: rxtx at allenjb.me.uk (AllenJB) Date: Mon, 11 Aug 2008 15:06:36 +0100 Subject: [Rxtx] Disabling EV_RXFLAG Message-ID: <48A0476C.2090800@allenjb.me.uk> Hi all, I'm working with a device which does not use an EvtChar and need to disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an event mask of FD 01 00 00. The reference software I have uses FB 00 00 00. With the rxtx mask I get framing errors which I believe are caused when the EvtChar is received. Is there currently a way with rxtx (I've using rxtx from Java) to disable EV_RXFLAG? If not from Java, where would I start if I wanted to turn the EV_RXFLAG option off in the C code? I've had a grep of the rxtx source code, but I can't see where EV_RXFLAG is being set. Thanks in advance, AllenJB From tjarvi at qbang.org Mon Aug 11 14:17:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Aug 2008 14:17:27 -0600 (MDT) Subject: [Rxtx] Disabling EV_RXFLAG In-Reply-To: <48A0476C.2090800@allenjb.me.uk> References: <48A0476C.2090800@allenjb.me.uk> Message-ID: On Mon, 11 Aug 2008, AllenJB wrote: > Hi all, > > I'm working with a device which does not use an EvtChar and need to > disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an > event mask of FD 01 00 00. The reference software I have uses FB 00 00 > 00. With the rxtx mask I get framing errors which I believe are caused > when the EvtChar is received. > > Is there currently a way with rxtx (I've using rxtx from Java) to > disable EV_RXFLAG? > > If not from Java, where would I start if I wanted to turn the EV_RXFLAG > option off in the C code? I've had a grep of the rxtx source code, but I > can't see where EV_RXFLAG is being set. > > Thanks in advance, > > AllenJB Hi Allen, I'd look at termios.c::tcsetattr() and termios.c::FillDCB() -- Trent Jarvi tjarvi at qbang.org From superdadusa at gmail.com Tue Aug 12 13:57:32 2008 From: superdadusa at gmail.com (John Choi) Date: Tue, 12 Aug 2008 13:57:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. Message-ID: Hi all, Just let you all know I just start to learn Java. I have download the serial comm package and the source code from open source communities.. I was able to verify with the given message string via serial monitor. when the given message string sends to the serial port then the character return added to the end of string by default if I use "Hello World" however if I changed to something else other than "Hello, World" there is no character return add to the end of string. I thing the library download from rxtx.org has implemented for the special strings. I can do like "login\n" in the string message to make character return but I don't want to add this individual custom character for each command return in every static message string I send, Can any who have done this might help me? Basically, something like this,, Write and add function to the program write a command, Reads the respond from a serial device.. Function handles multiple messages, Write: "com open" Read: Welcome to my world" expected Write: "admin" Read: Password?, expected Write: "admin" Read: you are successfully login terminal, expected. And I need to add a separate function handler handles a character return add to the each command above. If anyone can help this I can do the reset? Thank you in advance, John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0033.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SerialIO.java Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0033.pl From Steffen.DETTMER at ingenico.com Wed Aug 13 02:16:38 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 13 Aug 2008 10:16:38 +0200 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: References: Message-ID: <20080813081638.GA25412@elberon.bln.de.ingenico.com> * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > I can do like "login\n" in the string message to make character > return but I don't want to add this individual custom character > for each command return in every static message string I send, and why not?! > Can any who have done this might help me? what's about with writing a small wrapper function adding the carriage return? However, this would be slow, because either you call write two times (very bad) or the string needs to be copied, \n appended and written (since you are using Java Performance probably isn't so critical). Personally I would write `"login\n"' and `username + "\n"' etc., because since it is part of the command it should be part of the command definition string. > Basically, something like this,, Write and add function to the program write > a command, Reads the respond from a serial device.. correctly reading a `line' is more difficult. If you cannot make assumptions about timeouts and/or you need to have low delay, you need to read byte wise. If you need to save CPU resources you might need to add some buffering layer that you can read byte-wise but that is reading blockwise with some small timeout (lets say for serial lines something around byte transmission time times three or so). > /* > * To change this template, choose Tools | Templates > * and open the template in the editor. > */ :) > package joliba; > > /** > * > * @author root > */ :) > // derived from SUN's examples in the javax.comm package > import java.io.*; > import java.util.*; > //import javax.comm.*; // for SUN's serial/parallel port libraries > import gnu.io.*; // for rxtxSerial library > > public class SerialIO implements Runnable, SerialPortEventListener { > static CommPortIdentifier portId; > static CommPortIdentifier saveportId; > static Enumeration portList; > InputStream inputStream; > SerialPort serialPort; > Thread readThread; You need a thread for your synchronous RPC-style protocol? > static String messageString = "Hello, world!"; > static OutputStream outputStream; > static boolean outputBufferEmptyFlag = false; > > public static void main(String[] args) { > boolean portFound = false; > String defaultPort; > > // determine the name of the serial port on several operating systems > String osname = System.getProperty("os.name","").toLowerCase(); > if ( osname.startsWith("windows") ) { > // windows > defaultPort = "COM1"; > } else if (osname.startsWith("linux")) { > // linux > defaultPort = "/dev/ttyS0"; > } else if ( osname.startsWith("mac") ) { > // mac > defaultPort = "????"; > } else { > System.out.println("Sorry, your operating system is not supported"); > return; > } Is such a construction recommended? Isn't there some abstraction (like COM1 working on any platform)? [...] > try { > // activate the OUTPUT_BUFFER_EMPTY notifier > serialPort.notifyOnOutputEmpty(true); > } catch (Exception e) { > System.out.println("Error setting event notification"); > System.out.println(e.toString()); > System.exit(-1); > } I doubt that -1 is defined, probably some 127 or so would be the result, maybe better simply `throw e'? > public void writetoport() { > System.out.println("Writing \""+messageString+"\" to "+serialPort.getName()); > try { > // write string to serial port > outputStream.write(messageString.getBytes()); > } catch (IOException e) {} > } maybe something like /** * Writes the given output string and an additional carriage * return to the current outputStream. */ public void writeStringToPort( /** The output string (without CR). */ String output ) throws IOException { String outputLine = output + "\n"; outputStream.write(outputLine.getBytes()); } ? > > public SerialIO() { > // initalize serial port > try { > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > } catch (PortInUseException e) {} if the port is in use, you continue? Wonder that this works in Java, I would assume serialPort beeing uninitialized which AFAIK is an error in Java. > try { > inputStream = serialPort.getInputStream(); > } catch (IOException e) {} > > try { > serialPort.addEventListener(this); > } catch (TooManyListenersException e) {} > > // activate the DATA_AVAILABLE notifier > serialPort.notifyOnDataAvailable(true); > > try { > // set port parameters > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > } catch (UnsupportedCommOperationException e) {} > > // start the read thread > readThread = new Thread(this); > readThread.start(); > > } I think in all those exception cases you can abort, because it is unlikely that ignoring those errors allow a successful continuation, so in this case maybe it would be better to add a throw clause to the method. > public void run() { > // first thing in the thread, we initialize the write operation > initwritetoport(); > try { > while (true) { > // write string to port, the serialEvent will read it > writetoport(); > Thread.sleep(1000); > } > } catch (InterruptedException e) {} > } Does this make sense? Your `SimpleReadApp' writes one and the same string each second? > public void serialEvent(SerialPortEvent event) { > switch (event.getEventType()) { > case SerialPortEvent.BI: > case SerialPortEvent.OE: > case SerialPortEvent.FE: > case SerialPortEvent.PE: > case SerialPortEvent.CD: > case SerialPortEvent.CTS: > case SerialPortEvent.DSR: > case SerialPortEvent.RI: > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > break; > case SerialPortEvent.DATA_AVAILABLE: > // we get here if data has been received > byte[] readBuffer = new byte[20]; > try { > // read data > while (inputStream.available() > 0) { > int numBytes = inputStream.read(readBuffer); > } > // print data > String result = new String(readBuffer); > System.out.println("Read: "+result); > } catch (IOException e) {} I doubt that this is correct. I would assume you will get a 20 bytes result always, if more bytes would be available they would be printed in a second line but if less bytes are read I'd assume that the buffer/result contains zero bytes from implicite readBuffer contents initialisation (zero is no string terminator in Java AFAIK). > break; > } > } > } oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From florianmanschwetus at gmx.de Wed Aug 13 06:09:31 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 13 Aug 2008 14:09:31 +0200 Subject: [Rxtx] someone has seen such errors? Message-ID: <48A2CEFB.90007@gmx.de> I mean my communication mostly works, but it is far from perfect could this be the reason? Florian Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/949b9947/attachment-0033.bin From superdadusa at gmail.com Wed Aug 13 08:40:32 2008 From: superdadusa at gmail.com (John Choi) Date: Wed, 13 Aug 2008 08:40:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: <20080813081638.GA25412@elberon.bln.de.ingenico.com> References: <20080813081638.GA25412@elberon.bln.de.ingenico.com> Message-ID: Thank you so much Steffen and I will try that suggestion. John On 8/13/08, Steffen DETTMER wrote: > > * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > > I can do like "login\n" in the string message to make character > > return but I don't want to add this individual custom character > > for each command return in every static message string I send, > > and why not?! > > > Can any who have done this might help me? > > what's about with writing a small wrapper function adding the > carriage return? > However, this would be slow, because either you call write two > times (very bad) or the string needs to be copied, \n appended > and written (since you are using Java Performance probably isn't > so critical). > > Personally I would write `"login\n"' and `username + "\n"' etc., > because since it is part of the command it should be part of the > command definition string. > > > Basically, something like this,, Write and add function to the program > write > > a command, Reads the respond from a serial device.. > > correctly reading a `line' is more difficult. If you cannot make > assumptions about timeouts and/or you need to have low delay, you > need to read byte wise. If you need to save CPU resources you > might need to add some buffering layer that you can read > byte-wise but that is reading blockwise with some small timeout > (lets say for serial lines something around byte transmission > time times three or so). > > > /* > > * To change this template, choose Tools | Templates > > * and open the template in the editor. > > */ > > :) > > > package joliba; > > > > /** > > * > > * @author root > > */ > > :) > > > // derived from SUN's examples in the javax.comm package > > import java.io.*; > > import java.util.*; > > //import javax.comm.*; // for SUN's serial/parallel port libraries > > import gnu.io.*; // for rxtxSerial library > > > > public class SerialIO implements Runnable, SerialPortEventListener { > > static CommPortIdentifier portId; > > static CommPortIdentifier saveportId; > > static Enumeration portList; > > InputStream inputStream; > > SerialPort serialPort; > > Thread readThread; > > You need a thread for your synchronous RPC-style protocol? > > > static String messageString = "Hello, world!"; > > static OutputStream outputStream; > > static boolean outputBufferEmptyFlag = false; > > > > public static void main(String[] args) { > > boolean portFound = false; > > String defaultPort; > > > > // determine the name of the serial port on several operating > systems > > String osname = System.getProperty("os.name","").toLowerCase(); > > if ( osname.startsWith("windows") ) { > > // windows > > defaultPort = "COM1"; > > } else if (osname.startsWith("linux")) { > > // linux > > defaultPort = "/dev/ttyS0"; > > } else if ( osname.startsWith("mac") ) { > > // mac > > defaultPort = "????"; > > } else { > > System.out.println("Sorry, your operating system is not > supported"); > > return; > > } > > Is such a construction recommended? Isn't there some abstraction > (like COM1 working on any platform)? > > [...] > > try { > > // activate the OUTPUT_BUFFER_EMPTY notifier > > serialPort.notifyOnOutputEmpty(true); > > } catch (Exception e) { > > System.out.println("Error setting event notification"); > > System.out.println(e.toString()); > > System.exit(-1); > > } > > I doubt that -1 is defined, probably some 127 or so would be the > result, maybe better simply `throw e'? > > > public void writetoport() { > > System.out.println("Writing \""+messageString+"\" to > "+serialPort.getName()); > > try { > > // write string to serial port > > outputStream.write(messageString.getBytes()); > > } catch (IOException e) {} > > } > > maybe something like > > /** > * Writes the given output string and an additional carriage > * return to the current outputStream. > */ > public void > writeStringToPort( > /** The output string (without CR). */ > String output > ) throws IOException > { > String outputLine = output + "\n"; > outputStream.write(outputLine.getBytes()); > } > > ? > > > > > public SerialIO() { > > // initalize serial port > > try { > > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > > } catch (PortInUseException e) {} > > if the port is in use, you continue? Wonder that this works in > Java, I would assume serialPort beeing uninitialized which AFAIK > is an error in Java. > > > try { > > inputStream = serialPort.getInputStream(); > > } catch (IOException e) {} > > > > try { > > serialPort.addEventListener(this); > > } catch (TooManyListenersException e) {} > > > > // activate the DATA_AVAILABLE notifier > > serialPort.notifyOnDataAvailable(true); > > > > try { > > // set port parameters > > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > } catch (UnsupportedCommOperationException e) {} > > > > // start the read thread > > readThread = new Thread(this); > > readThread.start(); > > > > } > > I think in all those exception cases you can abort, because it is > unlikely that ignoring those errors allow a successful > continuation, so in this case maybe it would be better to add a > throw clause to the method. > > > public void run() { > > // first thing in the thread, we initialize the write operation > > initwritetoport(); > > try { > > while (true) { > > // write string to port, the serialEvent will read it > > writetoport(); > > Thread.sleep(1000); > > } > > } catch (InterruptedException e) {} > > } > > Does this make sense? Your `SimpleReadApp' writes one and the > same string each second? > > > public void serialEvent(SerialPortEvent event) { > > switch (event.getEventType()) { > > case SerialPortEvent.BI: > > case SerialPortEvent.OE: > > case SerialPortEvent.FE: > > case SerialPortEvent.PE: > > case SerialPortEvent.CD: > > case SerialPortEvent.CTS: > > case SerialPortEvent.DSR: > > case SerialPortEvent.RI: > > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > > break; > > case SerialPortEvent.DATA_AVAILABLE: > > // we get here if data has been received > > byte[] readBuffer = new byte[20]; > > try { > > // read data > > while (inputStream.available() > 0) { > > int numBytes = inputStream.read(readBuffer); > > } > > // print data > > String result = new String(readBuffer); > > System.out.println("Read: "+result); > > } catch (IOException e) {} > > I doubt that this is correct. I would assume you will get a 20 > bytes result always, if more bytes would be available they would > be printed in a second line but if less bytes are read I'd assume > that the buffer/result contains zero bytes from implicite > readBuffer contents initialisation (zero is no string terminator > in Java AFAIK). > > > break; > > } > > } > > } > > oki, > > Steffen > > About Ingenico Throughout the world businesses rely on Ingenico for secure > and expedient electronic transaction acceptance. Ingenico products leverage > proven technology, established standards and unparalleled ergonomics to > provide optimal reliability, versatility and usability. This comprehensive > range of products is complemented by a global array of services and > partnerships, enabling businesses in a number of vertical sectors to accept > transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged > information. If you are not the addressee or authorized to receive this for > the addressee, you must not use, copy, disclose or take any action based on > this message or any information herein. If you have received this message in > error, please advise the sender immediately by reply e-mail and delete this > message. Thank you for your cooperation. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/73c4135c/attachment-0032.html From ajmas at sympatico.ca Sat Aug 16 07:15:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 09:15:41 -0400 Subject: [Rxtx] someone has seen such errors? In-Reply-To: <48A2CEFB.90007@gmx.de> References: <48A2CEFB.90007@gmx.de> Message-ID: <43B5E8DA-1D93-4D90-809B-AAF35FF724C5@sympatico.ca> On 13-Aug-08, at 08:09 , Florian Manschwetus wrote: > I mean my communication mostly works, but it is far from perfect > could this be the reason? > > Florian > > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control Judging by the error messages this looks related to the driver you are using. Do a search for the following string with you favourite search engine, it should turn up a few hits: ftdi_set_termios FAILED to set databits/stopbits/parity Andre From ajmas at sympatico.ca Sat Aug 16 19:12:04 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 21:12:04 -0400 Subject: [Rxtx] Using SerialPortEvent? Message-ID: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Hi, Could someone tell me how I should be using the SerialPortEvent? Am I meant to be waiting for data and then simply reading from the inputstream? If this is the case why no just block on an inputstream read? Andr? From tjarvi at qbang.org Sat Aug 16 19:41:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 16 Aug 2008 19:41:13 -0600 (MDT) Subject: [Rxtx] Using SerialPortEvent? In-Reply-To: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> References: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Message-ID: On Sat, 16 Aug 2008, Andre-John Mas wrote: > Hi, > > Could someone tell me how I should be using the SerialPortEvent? Am I > meant to be waiting for data and then simply reading from the > inputstream? If this is the case why no just block on an inputstream > read? > Polling for data is fine also. It really depends upon what you are trying to do. For instance, if you require x bytes before reading, you can start polling after data is available. If you read on the same thread as your GUI and are waiting for data in a read, the results may be less than desirable. Java programming is 'usually' event driven rather than polling based. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sat Aug 16 20:10:39 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 22:10:39 -0400 Subject: [Rxtx] Using SerialPortEvent? In-Reply-To: References: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Message-ID: <3E495D4C-BB28-4845-A6AB-984C9A826BDF@sympatico.ca> On 16-Aug-08, at 21:41 , Trent Jarvi wrote: > On Sat, 16 Aug 2008, Andre-John Mas wrote: > >> Hi, >> >> Could someone tell me how I should be using the SerialPortEvent? Am I >> meant to be waiting for data and then simply reading from the >> inputstream? If this is the case why no just block on an inputstream >> read? >> > > Polling for data is fine also. It really depends upon what you are > trying to do. For instance, if you require x bytes before reading, > you can start polling after data is available. If you read on the > same thread as your GUI and are waiting for data in a read, the > results may be less than desirable. > > Java programming is 'usually' event driven rather than polling based. Sounds good. I thought I would use this opportunity to provide a event based version of the TwoWaySerialComm example. Could you just validate it before I add it to the Wiki: package ajmas74.experimental; import gnu.io.CommPort; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; import gnu.io.SerialPortEvent; import gnu.io.SerialPortEventListener; import java.io.IOException; import java.io.InputStream; import java.io.OutputStream; /** * This version of the TwoWaySerialComm example makes use of the * SerialPortEventListener to avoid polling. * * @author ajmas * */ public class TwoWaySerialComm { public TwoWaySerialComm() { super(); } void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { CommPort commPort = portIdentifier.open(this.getClass().getName(),2000); if ( commPort instanceof SerialPort ) { SerialPort serialPort = (SerialPort) commPort; serialPort .setSerialPortParams (57600 ,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); (new Thread(new SerialWriter(out))).start(); serialPort.addEventListener(new SerialReader(in)); } else { System.out.println("Error: Only serial ports are handled by this example."); } } } /** * Handles the input coming from the serial port. A new line character * is treated as the end of a block in this example. */ public static class SerialReader implements SerialPortEventListener { private InputStream in; private byte[] buffer = new byte[1024]; public SerialReader ( InputStream in ) { this.in = in; } public void serialEvent(SerialPortEvent arg0) { int data; try { int len = 0; while ( ( data = in.read()) > -1 ) { if ( data != '\n' ) { break; } buffer[len++] = (byte) data; } System.out.print(new String(buffer,0,len)); } catch ( IOException e ) { e.printStackTrace(); System.exit(-1); } } } /** */ public static class SerialWriter implements Runnable { OutputStream out; public SerialWriter ( OutputStream out ) { this.out = out; } public void run () { try { int c = 0; while ( ( c = System.in.read()) > -1 ) { this.out.write(c); } } catch ( IOException e ) { e.printStackTrace(); System.exit(-1); } } } public static void main ( String[] args ) { try { (new TwoWaySerialComm()).connect("COM3"); } catch ( Exception e ) { e.printStackTrace(); } } } From lfarkas at lfarkas.org Tue Aug 19 07:32:59 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Tue, 19 Aug 2008 15:32:59 +0200 Subject: [Rxtx] JNI or CNI Message-ID: <48AACB8B.9060606@lfarkas.org> hi, what is the current recommended way to rxtx on linux JNI or it's better to use CNI? is the CNI version fully functional and the same level as the JNI? i currently try to make a rhel/centos/fedora rpm for rxtx but has many problems with the standard dir structure. yours. -- Levente "Si vis pacem para bellum!" From lfarkas at lfarkas.org Tue Aug 19 08:47:34 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Tue, 19 Aug 2008 16:47:34 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel Message-ID: <48AADD06.7040809@lfarkas.org> hi, newer or not so newer linux kernel do not contain the UTS_RELEASE so the current rxtx is not compile on the latest kernels. even if it's commented out in the cvs configure there are other places. i attcahed a patch which fix it (or at least doesn't cause error at non-debug build). ps. is there any plan to the new 2.1-8 release in the near future? there are many changes (at least the license change in all file and in this case create a diff is very difficult)? the latest release more then 2 years old:-( -- Levente "Si vis pacem para bellum!" -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-2.1-uts.patch Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080819/ab5d38ac/attachment-0026.pl From ajmas at sympatico.ca Tue Aug 19 16:21:53 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 19 Aug 2008 18:21:53 -0400 Subject: [Rxtx] Event based example Message-ID: <24735BFB-B088-4B84-8173-FE98DF63B12F@sympatico.ca> Hi, I have just posted an example of using SerialPortEventListener in the Wiki: http://rxtx.qbang.org/wiki/index.php/Event_Based_Two_Way_Communication If you see any issues please could you let me know, or makes the changes. Andre From Martin.Oberhuber at windriver.com Fri Aug 22 04:02:24 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 22 Aug 2008 12:02:24 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <48AADD06.7040809@lfarkas.org> References: <48AADD06.7040809@lfarkas.org> Message-ID: <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> Farkas, there are indeed efforts to get a new RXTX release out the door. Your experience as a package maintainer would likely be helpful during these efforts, since I'd think it makes sense to keep the patches minimal that you must make to have the source compile in your environment. What are the things that you find problematic, apart from the UTS thing that you have mentioned before? What is the timing that you have in mind for your package? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Farkas Levente > Sent: Tuesday, August 19, 2008 4:48 PM > To: rxtx at qbang.org > Subject: [Rxtx] UTS_RELEASE not defined in newer kernel > > hi, > newer or not so newer linux kernel do not contain the > UTS_RELEASE so the > current rxtx is not compile on the latest kernels. even if it's > commented out in the cvs configure there are other places. > i attcahed a patch which fix it (or at least doesn't cause error at > non-debug build). > > ps. is there any plan to the new 2.1-8 release in the near > future? there > are many changes (at least the license change in all file and in this > case create a diff is very difficult)? the latest release more then 2 > years old:-( > > -- > Levente "Si vis pacem para bellum!" > From lfarkas at lfarkas.org Fri Aug 22 04:36:26 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Fri, 22 Aug 2008 12:36:26 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> References: <48AADD06.7040809@lfarkas.org> <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> Message-ID: <48AE96AA.6090505@lfarkas.org> hi, the packages already build for fedora-9 and centos-5 and here: http://www.lfarkas.org/linux/packages/ what i've to patch, the UTS, the configure script, but it's already fixed in the cvs (in another way) and the loadlibrary. the reasons for last one can be found here: https://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_files_that_use_JNI after we test it i'd like to add these packages to fedora and epel main repository (that's why it's be useful a new release after 2 years:-) imho versions are cheap and why not just release 2.1-8? the real code changes are minimal and if something critical bug found still can release 2.1-9:-) ps. and would be better to use simple number for version like 2.1-7 rather then 2.1-7v2. Oberhuber, Martin wrote: > Farkas, > > there are indeed efforts to get a new RXTX release out the > door. Your experience as a package maintainer would likely > be helpful during these efforts, since I'd think it makes > sense to keep the patches minimal that you must make to > have the source compile in your environment. > > What are the things that you find problematic, apart from > the UTS thing that you have mentioned before? > > What is the timing that you have in mind for your package? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >> On Behalf Of Farkas Levente >> Sent: Tuesday, August 19, 2008 4:48 PM >> To: rxtx at qbang.org >> Subject: [Rxtx] UTS_RELEASE not defined in newer kernel >> >> hi, >> newer or not so newer linux kernel do not contain the >> UTS_RELEASE so the >> current rxtx is not compile on the latest kernels. even if it's >> commented out in the cvs configure there are other places. >> i attcahed a patch which fix it (or at least doesn't cause error at >> non-debug build). >> >> ps. is there any plan to the new 2.1-8 release in the near >> future? there >> are many changes (at least the license change in all file and in this >> case create a diff is very difficult)? the latest release more then 2 >> years old:-( >> >> -- >> Levente "Si vis pacem para bellum!" >> -- Levente "Si vis pacem para bellum!" From tjarvi at qbang.org Fri Aug 22 18:50:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Aug 2008 18:50:32 -0600 (MDT) Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <48AE96AA.6090505@lfarkas.org> References: <48AADD06.7040809@lfarkas.org> <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> <48AE96AA.6090505@lfarkas.org> Message-ID: Hi Farkas, The v2 was simply the second build - no code changes. We are comming out with a new release shortly. I would encourage working with distros as you are. The building of rxtx turns out to be a bottle neck in quick releases. We do want stable releases that work for a year or more but I would have no problems with quicker cycles on developing work. I would have no problem working with someone that did builds that receive less testing more often but they do have to come out for multiple platforms from this end. Thanks for the links. On Fri, 22 Aug 2008, Farkas Levente wrote: > hi, > the packages already build for fedora-9 and centos-5 and here: > http://www.lfarkas.org/linux/packages/ > what i've to patch, the UTS, the configure script, but it's already > fixed in the cvs (in another way) and the loadlibrary. the reasons for > last one can be found here: > https://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_files_that_use_JNI > after we test it i'd like to add these packages to fedora and epel main > repository (that's why it's be useful a new release after 2 years:-) > imho versions are cheap and why not just release 2.1-8? the real code > changes are minimal and if something critical bug found still can > release 2.1-9:-) > > ps. and would be better to use simple number for version like 2.1-7 > rather then 2.1-7v2. > > Oberhuber, Martin wrote: >> Farkas, >> >> there are indeed efforts to get a new RXTX release out the >> door. Your experience as a package maintainer would likely >> be helpful during these efforts, since I'd think it makes >> sense to keep the patches minimal that you must make to >> have the source compile in your environment. >> >> What are the things that you find problematic, apart from >> the UTS thing that you have mentioned before? >> >> What is the timing that you have in mind for your package? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >>> On Behalf Of Farkas Levente >>> Sent: Tuesday, August 19, 2008 4:48 PM >>> To: rxtx at qbang.org >>> Subject: [Rxtx] UTS_RELEASE not defined in newer kernel >>> >>> hi, >>> newer or not so newer linux kernel do not contain the >>> UTS_RELEASE so the >>> current rxtx is not compile on the latest kernels. even if it's >>> commented out in the cvs configure there are other places. >>> i attcahed a patch which fix it (or at least doesn't cause error at >>> non-debug build). >>> >>> ps. is there any plan to the new 2.1-8 release in the near >>> future? there >>> are many changes (at least the license change in all file and in this >>> case create a diff is very difficult)? the latest release more then 2 >>> years old:-( >>> >>> -- >>> Levente "Si vis pacem para bellum!" >>> > > > From andy at triera.net Sat Aug 23 15:17:44 2008 From: andy at triera.net (Andy Rozman) Date: Sat, 23 Aug 2008 21:17:44 +0000 Subject: [Rxtx] port not identified on FreeBSD In-Reply-To: References: Message-ID: <48B07E78.2030306@triera.net> Hi ! I have one small problem... I have started using FreeBSD in last few days and I have come accross a problem with rxtx on FreeBSD. I am using usb-to-serial converter, which is identified under FreeBSD without problem as ucom0, and creates link under /dev called ttyU0, which is correct way to be done under FreeBSD (if device would be unidentified it would be called ugen0 - as usb generic). Problem is that I say to rxtx to get my all serial ports this one is not among them. Which names are permissable under linux-like implementations? Which will be accepted as serial ports? Andy From tjarvi at qbang.org Sat Aug 23 13:57:45 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 23 Aug 2008 13:57:45 -0600 (MDT) Subject: [Rxtx] port not identified on FreeBSD In-Reply-To: <48B07E78.2030306@triera.net> References: <48B07E78.2030306@triera.net> Message-ID: On Sat, 23 Aug 2008, Andy Rozman wrote: > Hi ! > > I have one small problem... I have started using FreeBSD in last few > days and I have come accross a problem with rxtx on FreeBSD. > > I am using usb-to-serial converter, which is identified under FreeBSD > without problem as ucom0, and creates link under /dev called > ttyU0, which is correct way to be done under FreeBSD (if device would be > unidentified it would be called ugen0 - as usb generic). Problem is that > I say to rxtx to get my all serial ports this one is not among them. > Which names are permissable under linux-like implementations? Which will > be accepted as serial ports? > > Andy > Thanks Andy! We will add ttyU* to FreeBSD. For now you can use properties to enable the port. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting#How_does_rxtx_detect_ports.3F__Can_I_override_it.3F The fix: diff -u -r1.16.2.59 RXTXCommDriver.java --- RXTXCommDriver.java 18 Nov 2007 22:32:41 -0000 1.16.2.59 +++ RXTXCommDriver.java 23 Aug 2008 19:55:25 -0000 @@ -644,6 +644,7 @@ { String[] Temp = { "ttyd", //general purpose serial ports + "ttyU", //general purpose USB serial ports "cuaa", //dialout serial ports "ttyA", //Specialix SI/XIO dialin ports "cuaA", //Specialix SI/XIO dialout ports -- Trent Jarvi tjarvi at qbang.org From rick_knight at rlknight.com Mon Aug 4 13:25:10 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Mon, 04 Aug 2008 12:25:10 -0700 Subject: [Rxtx] Sun's Comm API? Message-ID: <48975796.4010600@rlknight.com> I have an application that requires the javax compatible version of RXTX and Sun's comm api. I've been able to download and extract the version of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api anywhere. Can someone tell me where I can find it? Or maybe send me a copy? Also, when I try to build RXTX, configure and make complete successfully but make install failes with this error libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 I've never come accross this error before. How can I get past it? Thanks, Rick From bboyes at systronix.com Mon Aug 4 19:10:01 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:10:01 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48975796.4010600@rlknight.com> References: <48975796.4010600@rlknight.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/cb9c6167/attachment-0042.html From bboyes at systronix.com Mon Aug 4 19:12:37 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:12:37 -0600 Subject: [Rxtx] Towards an RXTX release - CSR BT/USB chipset In-Reply-To: <488FB7E7.8000802@gmail.com> References: <460801A4097E3D4CA04CC64EE648584806C56CF0@ism-mail03.corp.ad.wrs.com> <13557-75390@sneakemail.com> <20980-23424@sneakemail.com> <488FB7E7.8000802@gmail.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/52236088/attachment-0042.html From tjarvi at qbang.org Mon Aug 4 19:42:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 19:42:21 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: On Mon, 4 Aug 2008, Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: > I have an application that requires the javax compatible > version of RXTX > and Sun's comm api. I've been able to download and extract > the version > of RXTX that I need (2.0-7pre2) but I can't find Sun's camm > api > anywhere. Can someone tell me where I can find it? Or maybe > send me a > > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm port > support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have just > a ZIP with only the .class JAR file - no source or docs), has a readme > with these comments: > > This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release.? The 2.0.3 release itself is > no longer distributed.? comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project.? The RxTx project (http://www.rxtx.org ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org) was opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support.? Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins.? Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > ? > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > I hope that is helpful! > It would be nice to work with Sun to resolve those longstanding issues. But it may not be practical unless the process goes as fast and painless as the grandfathering of commapi did. Another option may be the old kaffe extensions that moved to gnu classpathx. These don't have the native libraries but should provide the 2.0 interface and the javax.comm.properties mechansim for SPI. http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Mon Aug 4 20:23:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Mon, 04 Aug 2008 20:23:57 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4897B9BD.5070809@ergotech.com> Has there been any work/would it be possible, to layer a javacomm look-alike on top of the GNU code? The goal is not to move the javax code forward, but to emulate the "legacy" javax packages for people who still need this. Jim Trent Jarvi wrote: > On Mon, 4 Aug 2008, Bruce Boyes wrote: > >> At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible >> version of RXTX >> and Sun's comm api. I've been able to download and extract >> the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm >> api >> anywhere. Can someone tell me where I can find it? Or maybe >> send me a >> >> >> javaxcomm has had a sort of on-again off-again history. The windoze >> version has been languishing for years (literally) but there are newer >> versions for other OS's. >> >> We try to keep links on one of our help pages current: >> http://www.practicalembeddedjava.com/tools/javatools_list.html >> which gets you to here: >> http://java.sun.com/products/javacomm/ >> where it says in fact they no longer even support Windows and Mac: >> "Implementations of the API are currently available for Solaris SPARC, >> Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so >> someone could support it. But I guess that's part of the reason RXTX >> exists! >> >> So one of Sun's own products, SunSPOT, has to use RXTX to get comm port >> support. >> >> The version we use is 2.0 from 11/15/1998. I have posted it on our >> website, which is within the terms of the license agreement contained >> therein (as I understand it). >> >> The last version of javaxcomm for Windows, 2.0.3, (for which I have just >> a ZIP with only the .class JAR file - no source or docs), has a readme >> with these comments: >> >> This distribution contains the comm.jar file original part >> of the COMMAPI 2.0.3 release. The 2.0.3 release itself is >> no longer distributed. comm.jar, which contains the comm >> API java class files (eg. Sun's binary implementation of the >> interface classes), is being made available, unsupported, >> with no obligation to fix bugs, at the request of the RXTX >> project. The RxTx project (http://www.rxtx.org ), uses the >> comm.jar class files, but provides their own native library >> components to provide support for other platforms. >> >> The 2.0.3 comm.jar is being provided in this way because >> as of COMMAPI 3.x, the java binary implementation forked and >> became incompatible with the RxTx project's native code. >> Due to the lack of a clear business case, and to resource >> constraints, no additional resources are being >> provided to provide an alternative engineering solution >> at the time of writing. >> >> RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: >> >> Ultimately the COMMAPI would be better served if a Java >> Community Process JSR (http://www.jcp.org) was opened and >> the COMMAPI was rearchitected to provide a more pluggable >> framework to improve cross-platform support. Such an >> architecture would embody a better defined and better >> documented SPI interface, including a way for comm. ports >> to be revealed to the client application through the API >> via platform-aware plugins. Similarly, native code used >> to access comm port in general could be handled more >> flexibly using a plugin model, whereby on any platform, >> multiple native modules could be in use simultaneously. >> >> Since there are now various ways serial ports can be implemented >> and accessed, modular comm. port JNI native libraries would be >> of benefit insofar as removing the burden of over-generalization >> from any single native component, or inversely, by relieving the >> implicit constraint that comm. drivers be accessed only via a >> monolithic mechanism, such as the UNIX vnode interface. >> >> paul.klissner at sun.com >> 6/10/06 >> >> I hope that is helpful! >> > > It would be nice to work with Sun to resolve those longstanding issues. > But it may not be practical unless the process goes as fast and painless > as the grandfathering of commapi did. > > Another option may be the old kaffe extensions that moved to gnu > classpathx. These don't have the native libraries but should provide > the 2.0 interface and the javax.comm.properties mechansim for SPI. > > http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Mon Aug 4 21:09:15 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 21:09:15 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? Message-ID: Hi Jim, I will not step into the javax.comm namespace without Sun's explicite permission. I fully understand the pain point you are trying to address. In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm Linux) - which remains an integral part of rxtx. At the time it was a win for Sun and rxtx. The Sun commapi license is/was fairly clear that rxtx should not step into that namespace. It made sense as Sun was active in that space and rxtx may go into another namespace - it was an experiment in working with Sun. This may sound silly looking at something that happened almost 10 years ago. In a community of respect which Sun helped create, there is no question about what to do. I hope eventually Sun will step up and do a right thing too. I agree that this is hurting the API more than helping it. There are also questions about how to replace the API in the long term which includes HID support which isn't going well so far. Others that can't even look at Sun's javax.comm today and can look at Kaffe's contribution to classpathx can easily work around such restrictions. On Mon, 4 Aug 2008, Jim Redman wrote: > Has there been any work/would it be possible, to layer a javacomm > look-alike on top of the GNU code? > > The goal is not to move the javax code forward, but to emulate the > "legacy" javax packages for people who still need this. > > Jim > > Trent Jarvi wrote: >> >> It would be nice to work with Sun to resolve those longstanding issues. >> But it may not be practical unless the process goes as fast and painless >> as the grandfathering of commapi did. >> >> Another option may be the old kaffe extensions that moved to gnu >> classpathx. These don't have the native libraries but should provide >> the 2.0 interface and the javax.comm.properties mechansim for SPI. >> >> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From florianmanschwetus at gmx.de Tue Aug 5 05:04:46 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 13:04:46 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: References: <48971C1F.9020806@gmx.de> Message-ID: <489833CE.1040801@gmx.de> Just look at sendCommand in this method I have to place a Thread.sleep(20) after each byte send to get working. Even the event based receive doesn't work fine but this could be may stupidness. The specifikation document (it is on the last pages of the manual) for the beamer could be found on: http://www.optoma.co.uk/support.aspx Florian Manschwetus Trent Jarvi schrieb: > > Hi Florian > > Sorry for the top post in advance. I worry you may not see my answer > under all your code :) > > I have not received this email before. This is 500k of code which I > don't have time to read. I can spend about 5 min on each hobby email > and still get to work in the morning. I have a couple suggestions for > how to get an answer. > > First, cut out your comments and extra code so you can demonstrate the > question (I might even glance and see what is wrong then). Don't go for > a working final product. Isolate the problem using a simple program and > then ask with that as an example. If I did what you just did, I'd have > to post 3/4 of a million lines of code :) > > Second, join the rxtx mail-list and ask there. This will give you 100x > more eyes. I'll also read and try to follow. > > -- > taj > > > > On Mon, 4 Aug 2008, Florian Manschwetus wrote: > >> It could be that my university account is blocked by filters so >> resending from here. >> >> >> Topic is to control Optoma HD80 beamer using rs232 serial chat. >> This code is able to detect power state and switch the beamer on / off. >> connected is the beamer using a digitus usb 2.0 serial adapter with an >> FT232 USB-Serial adapter the systems architecture is amd64. >> >> Please take a look in the sendCommand routine i have to place theire >> those Thread.sleep to get it working. >> Now the question is this correct or is there a better way to get this >> working correctly? >> >> In the javadoc coming with the install i found this: >> setBaudBase >> >> public boolean setBaudBase(int BaudBase) >> throws UnsupportedCommOperationException, >> java.io.IOException >> >> Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 >> before using. >> >> could this explain the error? >> I attached my java source and the protocol description for the beamer >> (available on vendor website). >> >> thx, >> Florian Manschwetus >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: TestRS232.java Type: text/x-java Size: 9143 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0084.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0085.bin From michael.erskine at ketech.com Tue Aug 5 05:53:49 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Tue, 5 Aug 2008 12:53:49 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489833CE.1040801@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> > Just look at sendCommand in this method I have to place a > Thread.sleep(20) after each byte send to get working. Even the event > based receive doesn't work fine but this could be may stupidness. Hi Florian, Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. Regards, Michael Erskine. From florianmanschwetus at gmx.de Tue Aug 5 07:28:15 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:28:15 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> Message-ID: <4898556F.8000208@gmx.de> Michael Erskine schrieb: >> Just look at sendCommand in this method I have to place a >> Thread.sleep(20) after each byte send to get working. Even the event >> based receive doesn't work fine but this could be may stupidness. > > Hi Florian, > > Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. > > Regards, > Michael Erskine. > Ok, sounds fine for the receiving problem. But why i have to wait after each byte when sending a command squence? (the for loop in send command) Florian > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/284f350c/attachment-0041.bin From florianmanschwetus at gmx.de Tue Aug 5 07:44:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:44:14 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <4898592E.2020908@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >>> Just look at sendCommand in this method I have to place a >>> Thread.sleep(20) after each byte send to get working. Even the event >>> based receive doesn't work fine but this could be may stupidness. >> >> Hi Florian, >> >> Yes, naturally you'll have to wait for a response from the other end. >> Why not wait for notification from the event thread perhaps using a >> BlockingDeque rather than your LinkedList. Generally I >> try to decouple all input and output streams: in your case your >> application is operating synchronously like the "expect" program >> (http://expect.nist.gov/) so waits (or timeouts) will need to be >> factored in. >> >> Regards, >> Michael Erskine. >> > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) > > Florian Furthermore there is this basic baud with this confusing javadoc entry: public boolean setBaudBase(int BaudBase) throws UnsupportedCommOperationException, java.io.IOException Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 before using. maybe this could explain something Florian >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/006c7425/attachment-0041.bin From jredman at ergotech.com Tue Aug 5 09:13:36 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 05 Aug 2008 09:13:36 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: Message-ID: <48986E20.3060104@ergotech.com> Trent, So two issues: 1) Technically I'm still not sure how easy/practical a layer would be. The problems are always classes like listeners, and wrapping returns of gnu.io classes. I really see it as a "delegate" type of concept. Any thoughts or ideas of the practicality of this approach? The idea is not to modify RXTX. 2) Javax. The javax namespace does seem to be in widespread use outside of Sun (the same is true for the java namespace). The classpath extensions, or some other location, should be interested in a JavaComm implementation even if it does have dependencies on RXTX. Would you have any philosophical objection to an approach like that? Of course, I suspect it might be better if someone with that authority at Sun would admit that the javax namespace is already in the wild and that there is no problem with it being used within RXTX. Jim Trent Jarvi wrote: > Hi Jim, > > I will not step into the javax.comm namespace without Sun's explicite > permission. I fully understand the pain point you are trying to address. > > In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm > Linux) - which remains an integral part of rxtx. At the time it was a win for > Sun and rxtx. > > The Sun commapi license is/was fairly clear that rxtx should not step into that > namespace. It made sense as Sun was active in that space and rxtx may go into > another namespace - it was an experiment in working with Sun. > > This may sound silly looking at something that happened almost 10 years ago. > In a community of respect which Sun helped create, there is no question about > what to do. I hope eventually Sun will step up and do a right thing too. > > I agree that this is hurting the API more than helping it. There are also > questions about how to replace the API in the long term which includes HID > support which isn't going well so far. > > Others that can't even look at Sun's javax.comm today and can look at Kaffe's > contribution to classpathx can easily work around such restrictions. > > On Mon, 4 Aug 2008, Jim Redman wrote: > >> Has there been any work/would it be possible, to layer a javacomm >> look-alike on top of the GNU code? >> >> The goal is not to move the javax code forward, but to emulate the >> "legacy" javax packages for people who still need this. >> >> Jim >> >> Trent Jarvi wrote: >>> It would be nice to work with Sun to resolve those longstanding issues. >>> But it may not be practical unless the process goes as fast and painless >>> as the grandfathering of commapi did. >>> >>> Another option may be the old kaffe extensions that moved to gnu >>> classpathx. These don't have the native libraries but should provide >>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>> >>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From sandeep at genevasoftech.com Tue Aug 5 11:18:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Tue, 05 Aug 2008 22:48:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <48988B6C.5080409@genevasoftech.com> Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. *-- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/ad20f1cb/attachment-0041.html From Martin.Oberhuber at windriver.com Tue Aug 5 13:30:17 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Tue, 5 Aug 2008 21:30:17 +0200 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Sandeep, shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on Sol7 but I've successfully run it on Sol9 and Sol10. Or is your request really about a native 64bit variant? I'm afraid that then you're out of luck since I think that quite a bit of RXTX is not yet ready for 64 bit. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Sandeep Kumar K Sent: Tuesday, August 05, 2008 7:19 PM To: rxtx at qbang.org Subject: [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so for Solaris 9 Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. -- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/81b7f988/attachment-0041.html From tjarvi at qbang.org Tue Aug 5 22:38:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 22:38:34 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 5 Aug 2008, Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built > on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid that > then > you're out of luck since I think that quite a bit of RXTX is not yet > ready > for 64 bit. > While rxtx-2.1-7 probably has problems, The CVS code should be OK for 64 bit Solaris. If it isn't, let me know and I'll find which patch is missing. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Aug 5 23:13:00 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 23:13:00 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48986E20.3060104@ergotech.com> References: <48986E20.3060104@ergotech.com> Message-ID: On Tue, 5 Aug 2008, Jim Redman wrote: > Trent, > > So two issues: > > 1) Technically I'm still not sure how easy/practical a layer would be. The > problems are always classes like listeners, and wrapping returns of gnu.io > classes. I really see it as a "delegate" type of concept. Any thoughts or > ideas of the practicality of this approach? The idea is not to modify RXTX. I have not put too much thought into this. I assume you want what rxtx 2.0 provided to tie into javax.comm implementations. More classes could be added to rxtx 2.1-7 for SPI support. Maintaining rxtx-2.0 could also be handed to someone if they like. > > 2) Javax. The javax namespace does seem to be in widespread use outside of > Sun (the same is true for the java namespace). The classpath extensions, or > some other location, should be interested in a JavaComm implementation even > if it does have dependencies on RXTX. Would you have any philosophical > objection to an approach like that? > No problems. Classpathx would be a possible place to do it. I'd suggest thinking twice about what this involves in practical terms. You would be wanting to revive the 2.0 API while Sun is at 3.0 and grandfathering the JSR. This undermines the main reason (established api) for using the javax.comm namespace and does not leave such a project in a good position. The only win I see here is maintaining support for applications that can't migrate namespaces. Not that that isn't important. At some point it is going to be less work to just edit the bytecode :) Such a javax.comm effort would also be signing up new projects that decided to use the work up for concerns they probably will not understand or expect. That probably isn't a good path to facilitate for new projects at this time. We will put a good faith effort to work well with others but keep in mind the project has limited bandwidth for such efforts. > Of course, I suspect it might be better if someone with that authority at Sun > would admit that the javax namespace is already in the wild and that there is > no problem with it being used within RXTX. > > Jim > > Trent Jarvi wrote: >> Hi Jim, >> >> I will not step into the javax.comm namespace without Sun's explicite >> permission. I fully understand the pain point you are trying to address. >> >> In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java >> Comm Linux) - which remains an integral part of rxtx. At the time it was a >> win for Sun and rxtx. >> >> The Sun commapi license is/was fairly clear that rxtx should not step into >> that namespace. It made sense as Sun was active in that space and rxtx may >> go into another namespace - it was an experiment in working with Sun. >> >> This may sound silly looking at something that happened almost 10 years >> ago. In a community of respect which Sun helped create, there is no >> question about what to do. I hope eventually Sun will step up and do a >> right thing too. >> >> I agree that this is hurting the API more than helping it. There are also >> questions about how to replace the API in the long term which includes HID >> support which isn't going well so far. >> >> Others that can't even look at Sun's javax.comm today and can look at >> Kaffe's contribution to classpathx can easily work around such >> restrictions. >> >> On Mon, 4 Aug 2008, Jim Redman wrote: >> >>> Has there been any work/would it be possible, to layer a javacomm >>> look-alike on top of the GNU code? >>> >>> The goal is not to move the javax code forward, but to emulate the >>> "legacy" javax packages for people who still need this. >>> >>> Jim >>> >>> Trent Jarvi wrote: >>>> It would be nice to work with Sun to resolve those longstanding issues. >>>> But it may not be practical unless the process goes as fast and painless >>>> as the grandfathering of commapi did. >>>> >>>> Another option may be the old kaffe extensions that moved to gnu >>>> classpathx. These don't have the native libraries but should provide >>>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>>> >>>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From sandeep at genevasoftech.com Wed Aug 6 00:03:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Wed, 06 Aug 2008 11:33:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: <48993EB8.30107@genevasoftech.com> Thank you Mr. Martin for your suggestion. The native file which is given in rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am getting the following error . Any suggestions to solve this issue. I am using Solaris SPARC 64 bit machine. ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) thrown while loading gnu.io.RXTXCommDriver Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(Unknown Source) at java.lang.ClassLoader.loadLibrary(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) at com.ReadFromModem.main(ReadFromModem.java:84) * * *Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid > that then > you're out of luck since I think that quite a bit of RXTX is not yet ready > for 64 bit. > > Cheers, > -- > *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > ------------------------------------------------------------------------ > *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On > Behalf Of *Sandeep Kumar K > *Sent:* Tuesday, August 05, 2008 7:19 PM > *To:* rxtx at qbang.org > *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so > for Solaris 9 > > Hi, > > Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 > bit machine. The librxtxSerial.so given in website is for Solaris 8. > > *-- > > Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/1e920343/attachment-0041.html From tjarvi at qbang.org Wed Aug 6 00:21:42 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 00:21:42 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <48993EB8.30107@genevasoftech.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> <48993EB8.30107@genevasoftech.com> Message-ID: Hi Sandeep You may be out of luck unless you can compile the 2.1 src in CVS (requires gnu make and gcc). But you could try the ToyBox(R)(TM) which is a collection of WiLdLy untested cross compiled 2.1-7 binaries covering everything from the ibm z series to embeded arm/ppc. To give an idea how poorly these are tested, I don't even know if z series machines have a serial port. ftp://www.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Solaris They should at least match the binary types. Actually, I think if you use the rxtx jar from CVS with that file, it should 'work' as the fix for 64 bits was in java not the native code. You could just cd rxtx*/src; javac *.java then jar -cf RXTXcomm.jar `find -name \*.class` to create the hybrid which will complain about version information a bit. On Wed, 6 Aug 2008, Sandeep Kumar K wrote: > Thank you Mr. Martin for your suggestion. The native file which is given in > rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am > getting the following error . > Any suggestions to solve this issue. > I am using Solaris SPARC 64 bit machine. > > ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar > java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 > (Possible cause: architecture word > width mismatch) thrown while loading gnu.io.RXTXCommDriver > Exception in thread "main" java.lang.UnsatisfiedLinkError: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF > class: ELFCLASS64 (Possible cause: > architecture word width mismatch) > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(Unknown Source) > at java.lang.ClassLoader.loadLibrary(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > at com.ReadFromModem.main(ReadFromModem.java:84) > > * > * > > *Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > > > Oberhuber, Martin wrote: >> Sandeep, >> shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse >> variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on >> Sol7 but I've successfully run it on Sol9 and Sol10. >> Or is your request really about a native 64bit variant? I'm afraid that >> then >> you're out of luck since I think that quite a bit of RXTX is not yet ready >> for 64 bit. >> Cheers, >> -- >> *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> ------------------------------------------------------------------------ >> *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On >> Behalf Of *Sandeep Kumar K >> *Sent:* Tuesday, August 05, 2008 7:19 PM >> *To:* rxtx at qbang.org >> *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so >> for Solaris 9 >> >> Hi, >> >> Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 >> bit machine. The librxtxSerial.so given in website is for Solaris 8. >> >> *-- >> Thanks & Regards >> >> Sandeep Kumar K >> Sr. Software Engineer >> Geneva Software Technologies >> Whitefield, Bangalore >> Mob : 9880193454* >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> From michael.erskine at ketech.com Wed Aug 6 01:39:28 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 6 Aug 2008 08:39:28 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Florian Manschwetus wrote: > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) Hi Florian, I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. Regards, Michael Erskine. From florianmanschwetus at gmx.de Wed Aug 6 02:53:16 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 06 Aug 2008 10:53:16 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Message-ID: <4899667C.6010706@gmx.de> Michael Erskine schrieb: > Florian Manschwetus wrote: >> Ok, sounds fine for the receiving problem. >> But why i have to wait after each byte when sending a command squence? >> (the for loop in send command) > > Hi Florian, > I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. > > Regards, > Michael Erskine. > correct with a terminal on the other end it works, my idea was that this basic baud has some influence. Could some one explain what it is for? Florian > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/c2b4fa84/attachment-0041.bin From rick_knight at rlknight.com Wed Aug 6 13:01:07 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:01:07 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F4F3.3020707@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > I have an application (Readerware) that uses RXTX with Javax to access the serial port. This used to work fine under previous Linux' and Java, but something has changed, I assume with Java itself , that is causing the application to fail with a link error. The application is not able to find librxtxSerialParallel.so. RXTX supplies librxtxSerial.so and librxtxParallel.so, but not librxtxSerialParallel.so. Where can I get librxtxSerialParallel.so, or do I need it? Is something else causing the lib to not be found? Thanks, Rick Knight From rick_knight at rlknight.com Wed Aug 6 13:17:55 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:17:55 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F8E3.5060400@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Thanks for the reply. The developer of the app I'm trying to use (Readerware) has sent me a copy of the comm.api and I've copied the library (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar into the proper places. When I try to run the application, I get this error... Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: /usr/lib/libSolarisSerialParallel.so: /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not little-endian (Possible cause: endianness mismatch) Caught java.lang.UnsatisfiedLinkError: com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I while loading driver com.sun.comm.SolarisDriver Is there a way around this error? Thanks again, Rick Knight From jlar310 at gmail.com Wed Aug 6 13:37:42 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 14:37:42 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899F8E3.5060400@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > The developer of the app I'm trying to use (Readerware) has sent me a > copy of the comm.api and I've copied the library > (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar > into the proper places. When I try to run the application, I get this > error... > > Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: > /usr/lib/libSolarisSerialParallel.so: > /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not > little-endian (Possible cause: endianness mismatch) > Caught java.lang.UnsatisfiedLinkError: > com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I > > while loading driver com.sun.comm.SolarisDriver > > Is there a way around this error? What host OS are you running? From your original post it looks like 32 bit Linux. The libSolarisSerialParallel.so file is for Sun Solaris and will vary depending on the underlying hardware architecture as well. Sorry for the double post Rick, but I failed to send this to the list the first time... -- Jeff From rick_knight at rlknight.com Wed Aug 6 13:44:29 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:44:29 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: <4899FF1D.9030504@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > > >> The developer of the app I'm trying to use (Readerware) has sent me a >> copy of the comm.api and I've copied the library >> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >> into the proper places. When I try to run the application, I get this >> error... >> >> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >> /usr/lib/libSolarisSerialParallel.so: >> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >> little-endian (Possible cause: endianness mismatch) >> Caught java.lang.UnsatisfiedLinkError: >> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >> >> while loading driver com.sun.comm.SolarisDriver >> >> Is there a way around this error? >> > > What host OS are you running? From your original post it looks like 32 > bit Linux. > > The libSolarisSerialParallel.so file is for Sun Solaris and will vary > depending on the underlying hardware architecture as well. > > I'm running Kubuntu Linux (debian based). It's 32 bit. Rick Knight From jlar310 at gmail.com Wed Aug 6 15:33:23 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 16:33:23 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > I don't think Sun did binary libraries for Linux in the 2.0 version. Can someone with more historical experience than I confirm that? I recently tried to port a Comm API application from Solaris sparc to Linux x86 and likewise could not get my hands on the binary libraries. I eventually just re-wrote the code to use the gnu namespace packages and rxtx 2.1. What I don't understand is why your application vendor does not provide everything you need to run their software. FYI: I have librxtxParallel.so and librxtxSerial.so installed at JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is /usr/java/default which is actually a softlink to /usr/java/jre1.6.0_05. -- Jeff From defiantlew at yahoo.com.au Wed Aug 6 16:29:33 2008 From: defiantlew at yahoo.com.au (Lew L) Date: Thu, 7 Aug 2008 08:29:33 +1000 Subject: [Rxtx] Sun's Comm API Documentation References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> Message-ID: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> As a matter of interest is the Sun Comm API documentation available somewhere? I have tried the Sun site but it seems to have been removed. Unless I have missed the documentation for RXTX? I javadocced the RXTX source but information (to me) is minimal. Somewhere I got the impression that the Sun Comm API docs is, or was, compatible with RXTX, what is the best docs to use in conjuntion with RXTX and where may the be available? Cheers Lew From rick_knight at rlknight.com Wed Aug 6 17:18:33 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:18:33 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A3149.4050306@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff I'm not sure if I posted this here or not, but when I try to build RXTX from source I get this install error... make all-am make[1]: Entering directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' make[1]: Nothing to be done for `all-am'. make[1]: Leaving directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 Can you tell me how to get past this error and get RXTX built and installed? Thanks, Rick From bboyes at systronix.com Wed Aug 6 17:40:12 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Wed, 06 Aug 2008 17:40:12 -0600 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: At 16:29 08/06/2008, Lew L wrote: >As a matter of interest is the Sun Comm API documentation available >somewhere? I have tried the Sun site but it seems to have been removed. It's in the file we have posted, link in prev email (sorry, in a huge hurry right now). Javadocs definitely there. >Unless I have missed the documentation for RXTX? I javadocced the RXTX >source but information (to me) is minimal. >Somewhere I got the impression that the Sun Comm API docs is, or was, >compatible with RXTX, what is the best docs to use in conjuntion with RXTX >and where may the be available? Yeah, this is one of my concerns/beefs. There is little documentation for RXTX and it isn't just the same as javaxcomm. I would be willing to help out writing docs for RXTX! Yes really... esp if we can fix the Bluetooth issues. best regards Bruce >Cheers >Lew > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx ------- WWW.SYSTRONIX.COM ---------- Real embedded Java and much more +1-801-534-1017 Salt Lake City, USA From rick_knight at rlknight.com Wed Aug 6 17:54:08 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:54:08 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A39A0.2090309@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff, I would like for my vendor to switch to rxtx 2.1. It would make things much easier for me. I'm not sure why he's still using the javax compatible code. He's a small operation. Re-writing the code to use gnu namespace sounds like a major overhaul. Was it? Thanks, Rick From tjarvi at qbang.org Wed Aug 6 21:35:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:35:12 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: >> >>> Jeff wrote: >>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>>> >>>> >>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things > much easier for me. I'm not sure why he's still using the javax > compatible code. He's a small operation. Re-writing the code to use gnu > namespace sounds like a major overhaul. Was it? > Hi Jeff, The changes are fairly mechanical. Imports need to change and any explicite use of the namespace needs to change such as catching an exception. The following script was made for maintaining rxtx 2.0 but can apply to other needs. It is in the contrib dir with rxtx source. #!/bin/sh # Don't use! :) # # Sat, 03 May 2003 16:45:08 Modifications from J?rg Weule # Create a ed-cmd for the change of one pattern # case $1 in gnu) X=g/javax_comm/s+javax_comm+gnu_io+g ;; javax) X=g/gnu_io/s+gnu_io+javax_comm+g ;; *) echo;echo;echo From the top rxtx directory run;echo;echo -e \\t./ChangePackage.sh gnu;echo -e \\t\\tor;echo -e \\t./ChangePackage.sh javax;echo;echo; exit 0 ;; esac # # ed will be used to keep the owner and mode of the files unchanged. # We have run the ed-script for the characters '.' '/' as well. # "tr _ $D" do the change. # find . -type f -a -print | grep -v $0 | (while read F ; do ( echo $X; echo $X| tr _ /; echo $X| tr _ .; echo w; echo q ) | ed $F 2>&1 >/dev/null done ) # # Now we do little changes at the Makefiles. Hope that all we need. # find . -name Makefile\* -a -print | (while read F ; do cat < References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: On Thu, 7 Aug 2008, Lew L wrote: > As a matter of interest is the Sun Comm API documentation available > somewhere? I have tried the Sun site but it seems to have been removed. > > Unless I have missed the documentation for RXTX? I javadocced the RXTX > source but information (to me) is minimal. > Somewhere I got the impression that the Sun Comm API docs is, or was, > compatible with RXTX, what is the best docs to use in conjuntion with RXTX > and where may the be available? > Hi Lew, The documentation on Sun's website is accurate. The changes that are problematic in 3.0 are on the backside which rxtx used to plug into. http://java.sun.com/products/javacomm/reference/api/index.html CommPortIdentifier may have some minor differences (judging by the authors notes). -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Aug 6 21:46:08 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:46:08 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > If javax.comm.properties is properly installed and you are using a 2.0 version of Sun's commapi with rxtx 2.0, you should not see the library attempt to load libSolarisSerialParallel.so. Sun CommAPI 3.0 will not work with any version of rxtx as it is hard coded to use the shared library. See the INSTALL file with rxtx-2.0 source for more help with the properties file. -- Trent Jarvi tjarvi at qbang.org From jlar310 at gmail.com Thu Aug 7 06:32:06 2008 From: jlar310 at gmail.com (Jeff) Date: Thu, 7 Aug 2008 07:32:06 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > Jeff wrote: >> >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >> wrote: >> >>> >>> Jeff wrote: >>> >>>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>> wrote: >>>> >>>> >>>> >>>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things much > easier for me. I'm not sure why he's still using the javax compatible code. > He's a small operation. Re-writing the code to use gnu namespace sounds like > a major overhaul. Was it? I found it quite easy. In fact, in order to accommodate the transition, I actually separated all of the code that deals directly with the Comm API or RXTX into a helper class. The helper class was then coded to use reflection to determine which library was available and then instantiate the necessary objects. No direct imports of either library are used. The main application just needs to get it's hands on the IO streams and need not deal directly with the libraries. Other programs may not be so simple... But this doesn't really help you unless your vendor forks over the source code... -- Jeff From rick_knight at rlknight.com Thu Aug 7 09:47:12 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Thu, 07 Aug 2008 08:47:12 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: <489B1900.10108@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >>> wrote: >>> >>> >>>> Jeff wrote: >>>> >>>> >>>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>>> copy of the comm.api and I've copied the library >>>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>>> into the proper places. When I try to run the application, I get this >>>>>> error... >>>>>> >>>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>>> /usr/lib/libSolarisSerialParallel.so: >>>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>>> little-endian (Possible cause: endianness mismatch) >>>>>> Caught java.lang.UnsatisfiedLinkError: >>>>>> >>>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>>> >>>>>> while loading driver com.sun.comm.SolarisDriver >>>>>> >>>>>> Is there a way around this error? >>>>>> >>>>>> >>>>>> >>>>> What host OS are you running? From your original post it looks like 32 >>>>> bit Linux. >>>>> >>>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>>> depending on the underlying hardware architecture as well. >>>>> >>>>> >>>>> >>>>> >>>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>>> >>>> >>>> >>> I don't think Sun did binary libraries for Linux in the 2.0 version. >>> Can someone with more historical experience than I confirm that? >>> >>> I recently tried to port a Comm API application from Solaris sparc to >>> Linux x86 and likewise could not get my hands on the binary libraries. >>> I eventually just re-wrote the code to use the gnu namespace packages >>> and rxtx 2.1. >>> >>> What I don't understand is why your application vendor does not >>> provide everything you need to run their software. >>> >>> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >>> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >>> /usr/java/default which is actually a softlink to >>> /usr/java/jre1.6.0_05. >>> >>> >>> >> Jeff, >> >> I would like for my vendor to switch to rxtx 2.1. It would make things much >> easier for me. I'm not sure why he's still using the javax compatible code. >> He's a small operation. Re-writing the code to use gnu namespace sounds like >> a major overhaul. Was it? >> > > I found it quite easy. In fact, in order to accommodate the > transition, I actually separated all of the code that deals directly > with the Comm API or RXTX into a helper class. The helper class was > then coded to use reflection to determine which library was available > and then instantiate the necessary objects. No direct imports of > either library are used. The main application just needs to get it's > hands on the IO streams and need not deal directly with the libraries. > Other programs may not be so simple... > > But this doesn't really help you unless your vendor forks over the > source code... > > Jeff, This may not help me directly, but I'm going to forward this thread to the vendor. I think he'll be open to making things work. Thanks again, Rick Knight From agusmunioz at gmail.com Thu Aug 7 16:39:51 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Thu, 7 Aug 2008 19:39:51 -0300 Subject: [Rxtx] How to send ack? Message-ID: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Hi, I'm still learning about serial communication and I have some doubts. I've got this question about how to do the following thing in rxtx. I have this hardware that connect to a PC using a serial port. These hardware receives data from a telephone line, proccess it, and then send it forward to the serial port. I've used a program named wincomm that shows what information is send it through the serial port and I have the nex behaviour: The hardware has a buffer where all data is stored, that cannot be sent it through the seria port. The program reads the first data send it by the hardware, and keep reading the same data always. There is a button in the application that says enable Ack, and when I click, then the hardware start to send all the stored information, and all the information is shown. I write a class, using rxtx that reads the serial port, and the same thing happens, it remains reading the same (first) data all the time. And I thing something like the enable Ack I'm missing. How can I do this enable Ack from my java code using rxtx? Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080807/e0a0f9a1/attachment-0039.html From ajmas at sympatico.ca Thu Aug 7 18:26:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 7 Aug 2008 20:26:41 -0400 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: <4BF42297-81E2-4BB8-A89F-1D43588379AE@sympatico.ca> On 6-Aug-08, at 19:40 , Bruce Boyes wrote: >> Unless I have missed the documentation for RXTX? I javadocced the >> RXTX >> source but information (to me) is minimal. >> Somewhere I got the impression that the Sun Comm API docs is, or was, >> compatible with RXTX, what is the best docs to use in conjuntion >> with RXTX >> and where may the be available? > > Yeah, this is one of my concerns/beefs. There is little documentation > for RXTX and it isn't just the same as javaxcomm. > > I would be willing to help out writing docs for RXTX! Yes really... > esp if we can fix the Bluetooth issues. If you want to contribute documentation then the best place to do that is the wiki. If there is anything missing or that could be improved on then please do so. If there are any points that you would like to see improved, for which you don't have the knowledge then ask on the mailing list for a volunteer. Andre From florianmanschwetus at gmx.de Fri Aug 8 03:04:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Fri, 08 Aug 2008 11:04:14 +0200 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Message-ID: <489C0C0E.2020401@gmx.de> Agustin Mu?oz schrieb: > Hi, I'm still learning about serial communication and I have some > doubts. I've got this question about how to do the following thing in rxtx. > I have this hardware that connect to a PC using a serial port. These > hardware receives data from a telephone line, proccess it, and then send > it forward to the serial port. I've used a program named wincomm that > shows what information is send it through the serial port and I have the > nex behaviour: > > The hardware has a buffer where all data is stored, that cannot be sent > it through the seria port. > The program reads the first data send it by the hardware, and keep > reading the same data always. > There is a button in the application that says enable Ack, and when I > click, then the hardware start to send all the stored information, and > all the information is shown. > > I write a class, using rxtx that reads the serial port, and the same > thing happens, it remains reading the same (first) data all the time. > And I thing something like the enable Ack I'm missing. > How can I do this enable Ack from my java code using rxtx? Afaik, a look at man ascii reveals: Okt Dez Hex Char 006 6 06 ACK So, i hope this will do the job: send(6); florian > > Thanks in advance > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/5b4965f8/attachment-0039.bin From agusmunioz at gmail.com Fri Aug 8 16:31:00 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 19:31:00 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <489C0C0E.2020401@gmx.de> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> Message-ID: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Hi Florian, thanks for the answer. By send(6) you mean to get the port OutputStream and write a 6? I try that but it didn't work. Any suggestion? Thanks On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < florianmanschwetus at gmx.de> wrote: > Agustin Mu?oz schrieb: > > Hi, I'm still learning about serial communication and I have some doubts. >> I've got this question about how to do the following thing in rxtx. >> I have this hardware that connect to a PC using a serial port. These >> hardware receives data from a telephone line, proccess it, and then send it >> forward to the serial port. I've used a program named wincomm that shows >> what information is send it through the serial port and I have the nex >> behaviour: >> >> The hardware has a buffer where all data is stored, that cannot be sent >> it through the seria port. >> The program reads the first data send it by the hardware, and keep reading >> the same data always. >> There is a button in the application that says enable Ack, and when I >> click, then the hardware start to send all the stored information, and all >> the information is shown. >> >> I write a class, using rxtx that reads the serial port, and the same thing >> happens, it remains reading the same (first) data all the time. And I thing >> something like the enable Ack I'm missing. >> How can I do this enable Ack from my java code using rxtx? >> > Afaik, a look at man ascii reveals: > Okt Dez Hex Char > 006 6 06 ACK > So, i hope this will do the job: > send(6); > > florian > >> >> Thanks in advance >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/7f3fba42/attachment-0038.html From agusmunioz at gmail.com Fri Aug 8 18:39:27 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 21:39:27 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Message-ID: <988288430808081739x7f9e7889id82591d5a9e2b4f6@mail.gmail.com> Ok, Florian, it works!! my problem was that I've been sending, through the OutputStream, the bytes of 6 as a string: out.write("6".getBytes()); but then I realized that you can write an int on an OuptuStream, so I tried that and It works: out.write(6); Thank you for the guidance!! On Fri, Aug 8, 2008 at 7:31 PM, Agustin Mu?oz wrote: > Hi Florian, thanks for the answer. By send(6) you mean to get the port > OutputStream and write a 6? > > I try that but it didn't work. > > Any suggestion? > > Thanks > > > On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < > florianmanschwetus at gmx.de> wrote: > >> Agustin Mu?oz schrieb: >> >> Hi, I'm still learning about serial communication and I have some doubts. >>> I've got this question about how to do the following thing in rxtx. >>> I have this hardware that connect to a PC using a serial port. These >>> hardware receives data from a telephone line, proccess it, and then send it >>> forward to the serial port. I've used a program named wincomm that shows >>> what information is send it through the serial port and I have the nex >>> behaviour: >>> >>> The hardware has a buffer where all data is stored, that cannot be sent >>> it through the seria port. >>> The program reads the first data send it by the hardware, and keep >>> reading the same data always. >>> There is a button in the application that says enable Ack, and when I >>> click, then the hardware start to send all the stored information, and all >>> the information is shown. >>> >>> I write a class, using rxtx that reads the serial port, and the same >>> thing happens, it remains reading the same (first) data all the time. And I >>> thing something like the enable Ack I'm missing. >>> How can I do this enable Ack from my java code using rxtx? >>> >> Afaik, a look at man ascii reveals: >> Okt Dez Hex Char >> 006 6 06 ACK >> So, i hope this will do the job: >> send(6); >> >> florian >> >>> >>> Thanks in advance >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/b918ab3d/attachment-0038.html From florianmanschwetus at gmx.de Sat Aug 9 00:45:43 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Sat, 09 Aug 2008 08:45:43 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4899667C.6010706@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> Message-ID: <489D3D17.9090209@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >> Florian Manschwetus wrote: >>> Ok, sounds fine for the receiving problem. >>> But why i have to wait after each byte when sending a command squence? >>> (the for loop in send command) >> >> Hi Florian, >> I'd imagine you probably don't! You could send all bytes in one go and >> RXTX would send them. The problem is most probably the other end: >> perhaps it has a really small buffer, some non-standard UART, or a >> crazy timing issue. If you attach a terminal to your output and send >> all the bytes of a command in one go they should appear no problem. >> >> Regards, >> Michael Erskine. >> > correct with a terminal on the other end it works, my idea was that this > basic baud has some influence. Could some one explain what it is for? > > Florian To make it more clear, my problem is that i can't use: outputStream.write(byte[]); => Beamer doesn't understand the sequence. (mostly no answer when he answers then *001) when i use this construct instead: for (int i = 0; i < command.length; i++) { this.outputStream.write(command[i]); try { Thread.sleep(25); } catch (InterruptedException e) { // TODO Auto-generated catch block e.printStackTrace(); } } it works nearly reliable. So what could it be? This Basic Baud is what exactly? Florian -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080809/692304ee/attachment-0038.bin From tjarvi at qbang.org Sat Aug 9 16:37:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Aug 2008 16:37:19 -0600 (MDT) Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489D3D17.9090209@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> <489D3D17.9090209@gmx.de> Message-ID: On Sat, 9 Aug 2008, Florian Manschwetus wrote: > Florian Manschwetus schrieb: >> Michael Erskine schrieb: >>> Florian Manschwetus wrote: >>>> Ok, sounds fine for the receiving problem. >>>> But why i have to wait after each byte when sending a command squence? >>>> (the for loop in send command) >>> >>> Hi Florian, >>> I'd imagine you probably don't! You could send all bytes in one go and >>> RXTX would send them. The problem is most probably the other end: perhaps >>> it has a really small buffer, some non-standard UART, or a crazy timing >>> issue. If you attach a terminal to your output and send all the bytes of a >>> command in one go they should appear no problem. >>> >>> Regards, >>> Michael Erskine. >>> >> correct with a terminal on the other end it works, my idea was that this >> basic baud has some influence. Could some one explain what it is for? >> >> Florian > To make it more clear, > my problem is that i can't use: > outputStream.write(byte[]); > => Beamer doesn't understand the sequence. (mostly no answer when he answers > then *001) > > when i use this construct instead: > > for (int i = 0; i < command.length; i++) { > this.outputStream.write(command[i]); > try { > Thread.sleep(25); > } catch (InterruptedException e) { > // TODO Auto-generated catch block > e.printStackTrace(); > } > } > > it works nearly reliable. > > So what could it be? This Basic Baud is what exactly? > I suspect you are using the 'moon protocol' and don't know it. RXTX enables this by default. The buffer on the other end is first in first out while reading. If the buffer is full, the bits are hand carried to the moon and burried. Then if the other side reads a couple bytes, two more bytes go into the buffer followed by more moon protocol. The resulting array of bytes the other side reads may appear to be scrambled until you go to the moon, get the bits and insert them in the right place. Flow control can prevent the default moon protocol and throttles the communiation by almost writing a byte at a time as need be. Hardware flow control is preferable but software flow control should also work. Read and write can appear to hang if the other side is not connected. This is why we don't enable them all the time. If you can't use flow control, you have to take care with the moon protocol and give the other side time to read. That is what your slower version of write is doing. -- Trent Jarvi tjarvi at qbang.org From rxtx at allenjb.me.uk Mon Aug 11 08:06:36 2008 From: rxtx at allenjb.me.uk (AllenJB) Date: Mon, 11 Aug 2008 15:06:36 +0100 Subject: [Rxtx] Disabling EV_RXFLAG Message-ID: <48A0476C.2090800@allenjb.me.uk> Hi all, I'm working with a device which does not use an EvtChar and need to disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an event mask of FD 01 00 00. The reference software I have uses FB 00 00 00. With the rxtx mask I get framing errors which I believe are caused when the EvtChar is received. Is there currently a way with rxtx (I've using rxtx from Java) to disable EV_RXFLAG? If not from Java, where would I start if I wanted to turn the EV_RXFLAG option off in the C code? I've had a grep of the rxtx source code, but I can't see where EV_RXFLAG is being set. Thanks in advance, AllenJB From tjarvi at qbang.org Mon Aug 11 14:17:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Aug 2008 14:17:27 -0600 (MDT) Subject: [Rxtx] Disabling EV_RXFLAG In-Reply-To: <48A0476C.2090800@allenjb.me.uk> References: <48A0476C.2090800@allenjb.me.uk> Message-ID: On Mon, 11 Aug 2008, AllenJB wrote: > Hi all, > > I'm working with a device which does not use an EvtChar and need to > disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an > event mask of FD 01 00 00. The reference software I have uses FB 00 00 > 00. With the rxtx mask I get framing errors which I believe are caused > when the EvtChar is received. > > Is there currently a way with rxtx (I've using rxtx from Java) to > disable EV_RXFLAG? > > If not from Java, where would I start if I wanted to turn the EV_RXFLAG > option off in the C code? I've had a grep of the rxtx source code, but I > can't see where EV_RXFLAG is being set. > > Thanks in advance, > > AllenJB Hi Allen, I'd look at termios.c::tcsetattr() and termios.c::FillDCB() -- Trent Jarvi tjarvi at qbang.org From superdadusa at gmail.com Tue Aug 12 13:57:32 2008 From: superdadusa at gmail.com (John Choi) Date: Tue, 12 Aug 2008 13:57:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. Message-ID: Hi all, Just let you all know I just start to learn Java. I have download the serial comm package and the source code from open source communities.. I was able to verify with the given message string via serial monitor. when the given message string sends to the serial port then the character return added to the end of string by default if I use "Hello World" however if I changed to something else other than "Hello, World" there is no character return add to the end of string. I thing the library download from rxtx.org has implemented for the special strings. I can do like "login\n" in the string message to make character return but I don't want to add this individual custom character for each command return in every static message string I send, Can any who have done this might help me? Basically, something like this,, Write and add function to the program write a command, Reads the respond from a serial device.. Function handles multiple messages, Write: "com open" Read: Welcome to my world" expected Write: "admin" Read: Password?, expected Write: "admin" Read: you are successfully login terminal, expected. And I need to add a separate function handler handles a character return add to the each command above. If anyone can help this I can do the reset? Thank you in advance, John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0034.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SerialIO.java Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0034.pl From Steffen.DETTMER at ingenico.com Wed Aug 13 02:16:38 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 13 Aug 2008 10:16:38 +0200 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: References: Message-ID: <20080813081638.GA25412@elberon.bln.de.ingenico.com> * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > I can do like "login\n" in the string message to make character > return but I don't want to add this individual custom character > for each command return in every static message string I send, and why not?! > Can any who have done this might help me? what's about with writing a small wrapper function adding the carriage return? However, this would be slow, because either you call write two times (very bad) or the string needs to be copied, \n appended and written (since you are using Java Performance probably isn't so critical). Personally I would write `"login\n"' and `username + "\n"' etc., because since it is part of the command it should be part of the command definition string. > Basically, something like this,, Write and add function to the program write > a command, Reads the respond from a serial device.. correctly reading a `line' is more difficult. If you cannot make assumptions about timeouts and/or you need to have low delay, you need to read byte wise. If you need to save CPU resources you might need to add some buffering layer that you can read byte-wise but that is reading blockwise with some small timeout (lets say for serial lines something around byte transmission time times three or so). > /* > * To change this template, choose Tools | Templates > * and open the template in the editor. > */ :) > package joliba; > > /** > * > * @author root > */ :) > // derived from SUN's examples in the javax.comm package > import java.io.*; > import java.util.*; > //import javax.comm.*; // for SUN's serial/parallel port libraries > import gnu.io.*; // for rxtxSerial library > > public class SerialIO implements Runnable, SerialPortEventListener { > static CommPortIdentifier portId; > static CommPortIdentifier saveportId; > static Enumeration portList; > InputStream inputStream; > SerialPort serialPort; > Thread readThread; You need a thread for your synchronous RPC-style protocol? > static String messageString = "Hello, world!"; > static OutputStream outputStream; > static boolean outputBufferEmptyFlag = false; > > public static void main(String[] args) { > boolean portFound = false; > String defaultPort; > > // determine the name of the serial port on several operating systems > String osname = System.getProperty("os.name","").toLowerCase(); > if ( osname.startsWith("windows") ) { > // windows > defaultPort = "COM1"; > } else if (osname.startsWith("linux")) { > // linux > defaultPort = "/dev/ttyS0"; > } else if ( osname.startsWith("mac") ) { > // mac > defaultPort = "????"; > } else { > System.out.println("Sorry, your operating system is not supported"); > return; > } Is such a construction recommended? Isn't there some abstraction (like COM1 working on any platform)? [...] > try { > // activate the OUTPUT_BUFFER_EMPTY notifier > serialPort.notifyOnOutputEmpty(true); > } catch (Exception e) { > System.out.println("Error setting event notification"); > System.out.println(e.toString()); > System.exit(-1); > } I doubt that -1 is defined, probably some 127 or so would be the result, maybe better simply `throw e'? > public void writetoport() { > System.out.println("Writing \""+messageString+"\" to "+serialPort.getName()); > try { > // write string to serial port > outputStream.write(messageString.getBytes()); > } catch (IOException e) {} > } maybe something like /** * Writes the given output string and an additional carriage * return to the current outputStream. */ public void writeStringToPort( /** The output string (without CR). */ String output ) throws IOException { String outputLine = output + "\n"; outputStream.write(outputLine.getBytes()); } ? > > public SerialIO() { > // initalize serial port > try { > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > } catch (PortInUseException e) {} if the port is in use, you continue? Wonder that this works in Java, I would assume serialPort beeing uninitialized which AFAIK is an error in Java. > try { > inputStream = serialPort.getInputStream(); > } catch (IOException e) {} > > try { > serialPort.addEventListener(this); > } catch (TooManyListenersException e) {} > > // activate the DATA_AVAILABLE notifier > serialPort.notifyOnDataAvailable(true); > > try { > // set port parameters > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > } catch (UnsupportedCommOperationException e) {} > > // start the read thread > readThread = new Thread(this); > readThread.start(); > > } I think in all those exception cases you can abort, because it is unlikely that ignoring those errors allow a successful continuation, so in this case maybe it would be better to add a throw clause to the method. > public void run() { > // first thing in the thread, we initialize the write operation > initwritetoport(); > try { > while (true) { > // write string to port, the serialEvent will read it > writetoport(); > Thread.sleep(1000); > } > } catch (InterruptedException e) {} > } Does this make sense? Your `SimpleReadApp' writes one and the same string each second? > public void serialEvent(SerialPortEvent event) { > switch (event.getEventType()) { > case SerialPortEvent.BI: > case SerialPortEvent.OE: > case SerialPortEvent.FE: > case SerialPortEvent.PE: > case SerialPortEvent.CD: > case SerialPortEvent.CTS: > case SerialPortEvent.DSR: > case SerialPortEvent.RI: > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > break; > case SerialPortEvent.DATA_AVAILABLE: > // we get here if data has been received > byte[] readBuffer = new byte[20]; > try { > // read data > while (inputStream.available() > 0) { > int numBytes = inputStream.read(readBuffer); > } > // print data > String result = new String(readBuffer); > System.out.println("Read: "+result); > } catch (IOException e) {} I doubt that this is correct. I would assume you will get a 20 bytes result always, if more bytes would be available they would be printed in a second line but if less bytes are read I'd assume that the buffer/result contains zero bytes from implicite readBuffer contents initialisation (zero is no string terminator in Java AFAIK). > break; > } > } > } oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From florianmanschwetus at gmx.de Wed Aug 13 06:09:31 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 13 Aug 2008 14:09:31 +0200 Subject: [Rxtx] someone has seen such errors? Message-ID: <48A2CEFB.90007@gmx.de> I mean my communication mostly works, but it is far from perfect could this be the reason? Florian Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/949b9947/attachment-0034.bin From superdadusa at gmail.com Wed Aug 13 08:40:32 2008 From: superdadusa at gmail.com (John Choi) Date: Wed, 13 Aug 2008 08:40:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: <20080813081638.GA25412@elberon.bln.de.ingenico.com> References: <20080813081638.GA25412@elberon.bln.de.ingenico.com> Message-ID: Thank you so much Steffen and I will try that suggestion. John On 8/13/08, Steffen DETTMER wrote: > > * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > > I can do like "login\n" in the string message to make character > > return but I don't want to add this individual custom character > > for each command return in every static message string I send, > > and why not?! > > > Can any who have done this might help me? > > what's about with writing a small wrapper function adding the > carriage return? > However, this would be slow, because either you call write two > times (very bad) or the string needs to be copied, \n appended > and written (since you are using Java Performance probably isn't > so critical). > > Personally I would write `"login\n"' and `username + "\n"' etc., > because since it is part of the command it should be part of the > command definition string. > > > Basically, something like this,, Write and add function to the program > write > > a command, Reads the respond from a serial device.. > > correctly reading a `line' is more difficult. If you cannot make > assumptions about timeouts and/or you need to have low delay, you > need to read byte wise. If you need to save CPU resources you > might need to add some buffering layer that you can read > byte-wise but that is reading blockwise with some small timeout > (lets say for serial lines something around byte transmission > time times three or so). > > > /* > > * To change this template, choose Tools | Templates > > * and open the template in the editor. > > */ > > :) > > > package joliba; > > > > /** > > * > > * @author root > > */ > > :) > > > // derived from SUN's examples in the javax.comm package > > import java.io.*; > > import java.util.*; > > //import javax.comm.*; // for SUN's serial/parallel port libraries > > import gnu.io.*; // for rxtxSerial library > > > > public class SerialIO implements Runnable, SerialPortEventListener { > > static CommPortIdentifier portId; > > static CommPortIdentifier saveportId; > > static Enumeration portList; > > InputStream inputStream; > > SerialPort serialPort; > > Thread readThread; > > You need a thread for your synchronous RPC-style protocol? > > > static String messageString = "Hello, world!"; > > static OutputStream outputStream; > > static boolean outputBufferEmptyFlag = false; > > > > public static void main(String[] args) { > > boolean portFound = false; > > String defaultPort; > > > > // determine the name of the serial port on several operating > systems > > String osname = System.getProperty("os.name","").toLowerCase(); > > if ( osname.startsWith("windows") ) { > > // windows > > defaultPort = "COM1"; > > } else if (osname.startsWith("linux")) { > > // linux > > defaultPort = "/dev/ttyS0"; > > } else if ( osname.startsWith("mac") ) { > > // mac > > defaultPort = "????"; > > } else { > > System.out.println("Sorry, your operating system is not > supported"); > > return; > > } > > Is such a construction recommended? Isn't there some abstraction > (like COM1 working on any platform)? > > [...] > > try { > > // activate the OUTPUT_BUFFER_EMPTY notifier > > serialPort.notifyOnOutputEmpty(true); > > } catch (Exception e) { > > System.out.println("Error setting event notification"); > > System.out.println(e.toString()); > > System.exit(-1); > > } > > I doubt that -1 is defined, probably some 127 or so would be the > result, maybe better simply `throw e'? > > > public void writetoport() { > > System.out.println("Writing \""+messageString+"\" to > "+serialPort.getName()); > > try { > > // write string to serial port > > outputStream.write(messageString.getBytes()); > > } catch (IOException e) {} > > } > > maybe something like > > /** > * Writes the given output string and an additional carriage > * return to the current outputStream. > */ > public void > writeStringToPort( > /** The output string (without CR). */ > String output > ) throws IOException > { > String outputLine = output + "\n"; > outputStream.write(outputLine.getBytes()); > } > > ? > > > > > public SerialIO() { > > // initalize serial port > > try { > > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > > } catch (PortInUseException e) {} > > if the port is in use, you continue? Wonder that this works in > Java, I would assume serialPort beeing uninitialized which AFAIK > is an error in Java. > > > try { > > inputStream = serialPort.getInputStream(); > > } catch (IOException e) {} > > > > try { > > serialPort.addEventListener(this); > > } catch (TooManyListenersException e) {} > > > > // activate the DATA_AVAILABLE notifier > > serialPort.notifyOnDataAvailable(true); > > > > try { > > // set port parameters > > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > } catch (UnsupportedCommOperationException e) {} > > > > // start the read thread > > readThread = new Thread(this); > > readThread.start(); > > > > } > > I think in all those exception cases you can abort, because it is > unlikely that ignoring those errors allow a successful > continuation, so in this case maybe it would be better to add a > throw clause to the method. > > > public void run() { > > // first thing in the thread, we initialize the write operation > > initwritetoport(); > > try { > > while (true) { > > // write string to port, the serialEvent will read it > > writetoport(); > > Thread.sleep(1000); > > } > > } catch (InterruptedException e) {} > > } > > Does this make sense? Your `SimpleReadApp' writes one and the > same string each second? > > > public void serialEvent(SerialPortEvent event) { > > switch (event.getEventType()) { > > case SerialPortEvent.BI: > > case SerialPortEvent.OE: > > case SerialPortEvent.FE: > > case SerialPortEvent.PE: > > case SerialPortEvent.CD: > > case SerialPortEvent.CTS: > > case SerialPortEvent.DSR: > > case SerialPortEvent.RI: > > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > > break; > > case SerialPortEvent.DATA_AVAILABLE: > > // we get here if data has been received > > byte[] readBuffer = new byte[20]; > > try { > > // read data > > while (inputStream.available() > 0) { > > int numBytes = inputStream.read(readBuffer); > > } > > // print data > > String result = new String(readBuffer); > > System.out.println("Read: "+result); > > } catch (IOException e) {} > > I doubt that this is correct. I would assume you will get a 20 > bytes result always, if more bytes would be available they would > be printed in a second line but if less bytes are read I'd assume > that the buffer/result contains zero bytes from implicite > readBuffer contents initialisation (zero is no string terminator > in Java AFAIK). > > > break; > > } > > } > > } > > oki, > > Steffen > > About Ingenico Throughout the world businesses rely on Ingenico for secure > and expedient electronic transaction acceptance. Ingenico products leverage > proven technology, established standards and unparalleled ergonomics to > provide optimal reliability, versatility and usability. This comprehensive > range of products is complemented by a global array of services and > partnerships, enabling businesses in a number of vertical sectors to accept > transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged > information. If you are not the addressee or authorized to receive this for > the addressee, you must not use, copy, disclose or take any action based on > this message or any information herein. If you have received this message in > error, please advise the sender immediately by reply e-mail and delete this > message. Thank you for your cooperation. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/73c4135c/attachment-0033.html From ajmas at sympatico.ca Sat Aug 16 07:15:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 09:15:41 -0400 Subject: [Rxtx] someone has seen such errors? In-Reply-To: <48A2CEFB.90007@gmx.de> References: <48A2CEFB.90007@gmx.de> Message-ID: <43B5E8DA-1D93-4D90-809B-AAF35FF724C5@sympatico.ca> On 13-Aug-08, at 08:09 , Florian Manschwetus wrote: > I mean my communication mostly works, but it is far from perfect > could this be the reason? > > Florian > > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control Judging by the error messages this looks related to the driver you are using. Do a search for the following string with you favourite search engine, it should turn up a few hits: ftdi_set_termios FAILED to set databits/stopbits/parity Andre From ajmas at sympatico.ca Sat Aug 16 19:12:04 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 21:12:04 -0400 Subject: [Rxtx] Using SerialPortEvent? Message-ID: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Hi, Could someone tell me how I should be using the SerialPortEvent? Am I meant to be waiting for data and then simply reading from the inputstream? If this is the case why no just block on an inputstream read? Andr? From tjarvi at qbang.org Sat Aug 16 19:41:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 16 Aug 2008 19:41:13 -0600 (MDT) Subject: [Rxtx] Using SerialPortEvent? In-Reply-To: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> References: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Message-ID: On Sat, 16 Aug 2008, Andre-John Mas wrote: > Hi, > > Could someone tell me how I should be using the SerialPortEvent? Am I > meant to be waiting for data and then simply reading from the > inputstream? If this is the case why no just block on an inputstream > read? > Polling for data is fine also. It really depends upon what you are trying to do. For instance, if you require x bytes before reading, you can start polling after data is available. If you read on the same thread as your GUI and are waiting for data in a read, the results may be less than desirable. Java programming is 'usually' event driven rather than polling based. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sat Aug 16 20:10:39 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 22:10:39 -0400 Subject: [Rxtx] Using SerialPortEvent? In-Reply-To: References: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Message-ID: <3E495D4C-BB28-4845-A6AB-984C9A826BDF@sympatico.ca> On 16-Aug-08, at 21:41 , Trent Jarvi wrote: > On Sat, 16 Aug 2008, Andre-John Mas wrote: > >> Hi, >> >> Could someone tell me how I should be using the SerialPortEvent? Am I >> meant to be waiting for data and then simply reading from the >> inputstream? If this is the case why no just block on an inputstream >> read? >> > > Polling for data is fine also. It really depends upon what you are > trying to do. For instance, if you require x bytes before reading, > you can start polling after data is available. If you read on the > same thread as your GUI and are waiting for data in a read, the > results may be less than desirable. > > Java programming is 'usually' event driven rather than polling based. Sounds good. I thought I would use this opportunity to provide a event based version of the TwoWaySerialComm example. Could you just validate it before I add it to the Wiki: package ajmas74.experimental; import gnu.io.CommPort; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; import gnu.io.SerialPortEvent; import gnu.io.SerialPortEventListener; import java.io.IOException; import java.io.InputStream; import java.io.OutputStream; /** * This version of the TwoWaySerialComm example makes use of the * SerialPortEventListener to avoid polling. * * @author ajmas * */ public class TwoWaySerialComm { public TwoWaySerialComm() { super(); } void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { CommPort commPort = portIdentifier.open(this.getClass().getName(),2000); if ( commPort instanceof SerialPort ) { SerialPort serialPort = (SerialPort) commPort; serialPort .setSerialPortParams (57600 ,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); (new Thread(new SerialWriter(out))).start(); serialPort.addEventListener(new SerialReader(in)); } else { System.out.println("Error: Only serial ports are handled by this example."); } } } /** * Handles the input coming from the serial port. A new line character * is treated as the end of a block in this example. */ public static class SerialReader implements SerialPortEventListener { private InputStream in; private byte[] buffer = new byte[1024]; public SerialReader ( InputStream in ) { this.in = in; } public void serialEvent(SerialPortEvent arg0) { int data; try { int len = 0; while ( ( data = in.read()) > -1 ) { if ( data != '\n' ) { break; } buffer[len++] = (byte) data; } System.out.print(new String(buffer,0,len)); } catch ( IOException e ) { e.printStackTrace(); System.exit(-1); } } } /** */ public static class SerialWriter implements Runnable { OutputStream out; public SerialWriter ( OutputStream out ) { this.out = out; } public void run () { try { int c = 0; while ( ( c = System.in.read()) > -1 ) { this.out.write(c); } } catch ( IOException e ) { e.printStackTrace(); System.exit(-1); } } } public static void main ( String[] args ) { try { (new TwoWaySerialComm()).connect("COM3"); } catch ( Exception e ) { e.printStackTrace(); } } } From lfarkas at lfarkas.org Tue Aug 19 07:32:59 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Tue, 19 Aug 2008 15:32:59 +0200 Subject: [Rxtx] JNI or CNI Message-ID: <48AACB8B.9060606@lfarkas.org> hi, what is the current recommended way to rxtx on linux JNI or it's better to use CNI? is the CNI version fully functional and the same level as the JNI? i currently try to make a rhel/centos/fedora rpm for rxtx but has many problems with the standard dir structure. yours. -- Levente "Si vis pacem para bellum!" From lfarkas at lfarkas.org Tue Aug 19 08:47:34 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Tue, 19 Aug 2008 16:47:34 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel Message-ID: <48AADD06.7040809@lfarkas.org> hi, newer or not so newer linux kernel do not contain the UTS_RELEASE so the current rxtx is not compile on the latest kernels. even if it's commented out in the cvs configure there are other places. i attcahed a patch which fix it (or at least doesn't cause error at non-debug build). ps. is there any plan to the new 2.1-8 release in the near future? there are many changes (at least the license change in all file and in this case create a diff is very difficult)? the latest release more then 2 years old:-( -- Levente "Si vis pacem para bellum!" -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-2.1-uts.patch Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080819/ab5d38ac/attachment-0027.pl From ajmas at sympatico.ca Tue Aug 19 16:21:53 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 19 Aug 2008 18:21:53 -0400 Subject: [Rxtx] Event based example Message-ID: <24735BFB-B088-4B84-8173-FE98DF63B12F@sympatico.ca> Hi, I have just posted an example of using SerialPortEventListener in the Wiki: http://rxtx.qbang.org/wiki/index.php/Event_Based_Two_Way_Communication If you see any issues please could you let me know, or makes the changes. Andre From Martin.Oberhuber at windriver.com Fri Aug 22 04:02:24 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 22 Aug 2008 12:02:24 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <48AADD06.7040809@lfarkas.org> References: <48AADD06.7040809@lfarkas.org> Message-ID: <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> Farkas, there are indeed efforts to get a new RXTX release out the door. Your experience as a package maintainer would likely be helpful during these efforts, since I'd think it makes sense to keep the patches minimal that you must make to have the source compile in your environment. What are the things that you find problematic, apart from the UTS thing that you have mentioned before? What is the timing that you have in mind for your package? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Farkas Levente > Sent: Tuesday, August 19, 2008 4:48 PM > To: rxtx at qbang.org > Subject: [Rxtx] UTS_RELEASE not defined in newer kernel > > hi, > newer or not so newer linux kernel do not contain the > UTS_RELEASE so the > current rxtx is not compile on the latest kernels. even if it's > commented out in the cvs configure there are other places. > i attcahed a patch which fix it (or at least doesn't cause error at > non-debug build). > > ps. is there any plan to the new 2.1-8 release in the near > future? there > are many changes (at least the license change in all file and in this > case create a diff is very difficult)? the latest release more then 2 > years old:-( > > -- > Levente "Si vis pacem para bellum!" > From lfarkas at lfarkas.org Fri Aug 22 04:36:26 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Fri, 22 Aug 2008 12:36:26 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> References: <48AADD06.7040809@lfarkas.org> <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> Message-ID: <48AE96AA.6090505@lfarkas.org> hi, the packages already build for fedora-9 and centos-5 and here: http://www.lfarkas.org/linux/packages/ what i've to patch, the UTS, the configure script, but it's already fixed in the cvs (in another way) and the loadlibrary. the reasons for last one can be found here: https://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_files_that_use_JNI after we test it i'd like to add these packages to fedora and epel main repository (that's why it's be useful a new release after 2 years:-) imho versions are cheap and why not just release 2.1-8? the real code changes are minimal and if something critical bug found still can release 2.1-9:-) ps. and would be better to use simple number for version like 2.1-7 rather then 2.1-7v2. Oberhuber, Martin wrote: > Farkas, > > there are indeed efforts to get a new RXTX release out the > door. Your experience as a package maintainer would likely > be helpful during these efforts, since I'd think it makes > sense to keep the patches minimal that you must make to > have the source compile in your environment. > > What are the things that you find problematic, apart from > the UTS thing that you have mentioned before? > > What is the timing that you have in mind for your package? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >> On Behalf Of Farkas Levente >> Sent: Tuesday, August 19, 2008 4:48 PM >> To: rxtx at qbang.org >> Subject: [Rxtx] UTS_RELEASE not defined in newer kernel >> >> hi, >> newer or not so newer linux kernel do not contain the >> UTS_RELEASE so the >> current rxtx is not compile on the latest kernels. even if it's >> commented out in the cvs configure there are other places. >> i attcahed a patch which fix it (or at least doesn't cause error at >> non-debug build). >> >> ps. is there any plan to the new 2.1-8 release in the near >> future? there >> are many changes (at least the license change in all file and in this >> case create a diff is very difficult)? the latest release more then 2 >> years old:-( >> >> -- >> Levente "Si vis pacem para bellum!" >> -- Levente "Si vis pacem para bellum!" From tjarvi at qbang.org Fri Aug 22 18:50:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Aug 2008 18:50:32 -0600 (MDT) Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <48AE96AA.6090505@lfarkas.org> References: <48AADD06.7040809@lfarkas.org> <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> <48AE96AA.6090505@lfarkas.org> Message-ID: Hi Farkas, The v2 was simply the second build - no code changes. We are comming out with a new release shortly. I would encourage working with distros as you are. The building of rxtx turns out to be a bottle neck in quick releases. We do want stable releases that work for a year or more but I would have no problems with quicker cycles on developing work. I would have no problem working with someone that did builds that receive less testing more often but they do have to come out for multiple platforms from this end. Thanks for the links. On Fri, 22 Aug 2008, Farkas Levente wrote: > hi, > the packages already build for fedora-9 and centos-5 and here: > http://www.lfarkas.org/linux/packages/ > what i've to patch, the UTS, the configure script, but it's already > fixed in the cvs (in another way) and the loadlibrary. the reasons for > last one can be found here: > https://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_files_that_use_JNI > after we test it i'd like to add these packages to fedora and epel main > repository (that's why it's be useful a new release after 2 years:-) > imho versions are cheap and why not just release 2.1-8? the real code > changes are minimal and if something critical bug found still can > release 2.1-9:-) > > ps. and would be better to use simple number for version like 2.1-7 > rather then 2.1-7v2. > > Oberhuber, Martin wrote: >> Farkas, >> >> there are indeed efforts to get a new RXTX release out the >> door. Your experience as a package maintainer would likely >> be helpful during these efforts, since I'd think it makes >> sense to keep the patches minimal that you must make to >> have the source compile in your environment. >> >> What are the things that you find problematic, apart from >> the UTS thing that you have mentioned before? >> >> What is the timing that you have in mind for your package? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >>> On Behalf Of Farkas Levente >>> Sent: Tuesday, August 19, 2008 4:48 PM >>> To: rxtx at qbang.org >>> Subject: [Rxtx] UTS_RELEASE not defined in newer kernel >>> >>> hi, >>> newer or not so newer linux kernel do not contain the >>> UTS_RELEASE so the >>> current rxtx is not compile on the latest kernels. even if it's >>> commented out in the cvs configure there are other places. >>> i attcahed a patch which fix it (or at least doesn't cause error at >>> non-debug build). >>> >>> ps. is there any plan to the new 2.1-8 release in the near >>> future? there >>> are many changes (at least the license change in all file and in this >>> case create a diff is very difficult)? the latest release more then 2 >>> years old:-( >>> >>> -- >>> Levente "Si vis pacem para bellum!" >>> > > > From andy at triera.net Sat Aug 23 15:17:44 2008 From: andy at triera.net (Andy Rozman) Date: Sat, 23 Aug 2008 21:17:44 +0000 Subject: [Rxtx] port not identified on FreeBSD In-Reply-To: References: Message-ID: <48B07E78.2030306@triera.net> Hi ! I have one small problem... I have started using FreeBSD in last few days and I have come accross a problem with rxtx on FreeBSD. I am using usb-to-serial converter, which is identified under FreeBSD without problem as ucom0, and creates link under /dev called ttyU0, which is correct way to be done under FreeBSD (if device would be unidentified it would be called ugen0 - as usb generic). Problem is that I say to rxtx to get my all serial ports this one is not among them. Which names are permissable under linux-like implementations? Which will be accepted as serial ports? Andy From tjarvi at qbang.org Sat Aug 23 13:57:45 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 23 Aug 2008 13:57:45 -0600 (MDT) Subject: [Rxtx] port not identified on FreeBSD In-Reply-To: <48B07E78.2030306@triera.net> References: <48B07E78.2030306@triera.net> Message-ID: On Sat, 23 Aug 2008, Andy Rozman wrote: > Hi ! > > I have one small problem... I have started using FreeBSD in last few > days and I have come accross a problem with rxtx on FreeBSD. > > I am using usb-to-serial converter, which is identified under FreeBSD > without problem as ucom0, and creates link under /dev called > ttyU0, which is correct way to be done under FreeBSD (if device would be > unidentified it would be called ugen0 - as usb generic). Problem is that > I say to rxtx to get my all serial ports this one is not among them. > Which names are permissable under linux-like implementations? Which will > be accepted as serial ports? > > Andy > Thanks Andy! We will add ttyU* to FreeBSD. For now you can use properties to enable the port. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting#How_does_rxtx_detect_ports.3F__Can_I_override_it.3F The fix: diff -u -r1.16.2.59 RXTXCommDriver.java --- RXTXCommDriver.java 18 Nov 2007 22:32:41 -0000 1.16.2.59 +++ RXTXCommDriver.java 23 Aug 2008 19:55:25 -0000 @@ -644,6 +644,7 @@ { String[] Temp = { "ttyd", //general purpose serial ports + "ttyU", //general purpose USB serial ports "cuaa", //dialout serial ports "ttyA", //Specialix SI/XIO dialin ports "cuaA", //Specialix SI/XIO dialout ports -- Trent Jarvi tjarvi at qbang.org From rick_knight at rlknight.com Mon Aug 4 13:25:10 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Mon, 04 Aug 2008 12:25:10 -0700 Subject: [Rxtx] Sun's Comm API? Message-ID: <48975796.4010600@rlknight.com> I have an application that requires the javax compatible version of RXTX and Sun's comm api. I've been able to download and extract the version of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api anywhere. Can someone tell me where I can find it? Or maybe send me a copy? Also, when I try to build RXTX, configure and make complete successfully but make install failes with this error libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 I've never come accross this error before. How can I get past it? Thanks, Rick From bboyes at systronix.com Mon Aug 4 19:10:01 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:10:01 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48975796.4010600@rlknight.com> References: <48975796.4010600@rlknight.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/cb9c6167/attachment-0043.html From bboyes at systronix.com Mon Aug 4 19:12:37 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:12:37 -0600 Subject: [Rxtx] Towards an RXTX release - CSR BT/USB chipset In-Reply-To: <488FB7E7.8000802@gmail.com> References: <460801A4097E3D4CA04CC64EE648584806C56CF0@ism-mail03.corp.ad.wrs.com> <13557-75390@sneakemail.com> <20980-23424@sneakemail.com> <488FB7E7.8000802@gmail.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/52236088/attachment-0043.html From tjarvi at qbang.org Mon Aug 4 19:42:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 19:42:21 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: On Mon, 4 Aug 2008, Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: > I have an application that requires the javax compatible > version of RXTX > and Sun's comm api. I've been able to download and extract > the version > of RXTX that I need (2.0-7pre2) but I can't find Sun's camm > api > anywhere. Can someone tell me where I can find it? Or maybe > send me a > > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm port > support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have just > a ZIP with only the .class JAR file - no source or docs), has a readme > with these comments: > > This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release.? The 2.0.3 release itself is > no longer distributed.? comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project.? The RxTx project (http://www.rxtx.org ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org) was opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support.? Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins.? Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > ? > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > I hope that is helpful! > It would be nice to work with Sun to resolve those longstanding issues. But it may not be practical unless the process goes as fast and painless as the grandfathering of commapi did. Another option may be the old kaffe extensions that moved to gnu classpathx. These don't have the native libraries but should provide the 2.0 interface and the javax.comm.properties mechansim for SPI. http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Mon Aug 4 20:23:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Mon, 04 Aug 2008 20:23:57 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4897B9BD.5070809@ergotech.com> Has there been any work/would it be possible, to layer a javacomm look-alike on top of the GNU code? The goal is not to move the javax code forward, but to emulate the "legacy" javax packages for people who still need this. Jim Trent Jarvi wrote: > On Mon, 4 Aug 2008, Bruce Boyes wrote: > >> At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible >> version of RXTX >> and Sun's comm api. I've been able to download and extract >> the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm >> api >> anywhere. Can someone tell me where I can find it? Or maybe >> send me a >> >> >> javaxcomm has had a sort of on-again off-again history. The windoze >> version has been languishing for years (literally) but there are newer >> versions for other OS's. >> >> We try to keep links on one of our help pages current: >> http://www.practicalembeddedjava.com/tools/javatools_list.html >> which gets you to here: >> http://java.sun.com/products/javacomm/ >> where it says in fact they no longer even support Windows and Mac: >> "Implementations of the API are currently available for Solaris SPARC, >> Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so >> someone could support it. But I guess that's part of the reason RXTX >> exists! >> >> So one of Sun's own products, SunSPOT, has to use RXTX to get comm port >> support. >> >> The version we use is 2.0 from 11/15/1998. I have posted it on our >> website, which is within the terms of the license agreement contained >> therein (as I understand it). >> >> The last version of javaxcomm for Windows, 2.0.3, (for which I have just >> a ZIP with only the .class JAR file - no source or docs), has a readme >> with these comments: >> >> This distribution contains the comm.jar file original part >> of the COMMAPI 2.0.3 release. The 2.0.3 release itself is >> no longer distributed. comm.jar, which contains the comm >> API java class files (eg. Sun's binary implementation of the >> interface classes), is being made available, unsupported, >> with no obligation to fix bugs, at the request of the RXTX >> project. The RxTx project (http://www.rxtx.org ), uses the >> comm.jar class files, but provides their own native library >> components to provide support for other platforms. >> >> The 2.0.3 comm.jar is being provided in this way because >> as of COMMAPI 3.x, the java binary implementation forked and >> became incompatible with the RxTx project's native code. >> Due to the lack of a clear business case, and to resource >> constraints, no additional resources are being >> provided to provide an alternative engineering solution >> at the time of writing. >> >> RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: >> >> Ultimately the COMMAPI would be better served if a Java >> Community Process JSR (http://www.jcp.org) was opened and >> the COMMAPI was rearchitected to provide a more pluggable >> framework to improve cross-platform support. Such an >> architecture would embody a better defined and better >> documented SPI interface, including a way for comm. ports >> to be revealed to the client application through the API >> via platform-aware plugins. Similarly, native code used >> to access comm port in general could be handled more >> flexibly using a plugin model, whereby on any platform, >> multiple native modules could be in use simultaneously. >> >> Since there are now various ways serial ports can be implemented >> and accessed, modular comm. port JNI native libraries would be >> of benefit insofar as removing the burden of over-generalization >> from any single native component, or inversely, by relieving the >> implicit constraint that comm. drivers be accessed only via a >> monolithic mechanism, such as the UNIX vnode interface. >> >> paul.klissner at sun.com >> 6/10/06 >> >> I hope that is helpful! >> > > It would be nice to work with Sun to resolve those longstanding issues. > But it may not be practical unless the process goes as fast and painless > as the grandfathering of commapi did. > > Another option may be the old kaffe extensions that moved to gnu > classpathx. These don't have the native libraries but should provide > the 2.0 interface and the javax.comm.properties mechansim for SPI. > > http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Mon Aug 4 21:09:15 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 21:09:15 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? Message-ID: Hi Jim, I will not step into the javax.comm namespace without Sun's explicite permission. I fully understand the pain point you are trying to address. In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm Linux) - which remains an integral part of rxtx. At the time it was a win for Sun and rxtx. The Sun commapi license is/was fairly clear that rxtx should not step into that namespace. It made sense as Sun was active in that space and rxtx may go into another namespace - it was an experiment in working with Sun. This may sound silly looking at something that happened almost 10 years ago. In a community of respect which Sun helped create, there is no question about what to do. I hope eventually Sun will step up and do a right thing too. I agree that this is hurting the API more than helping it. There are also questions about how to replace the API in the long term which includes HID support which isn't going well so far. Others that can't even look at Sun's javax.comm today and can look at Kaffe's contribution to classpathx can easily work around such restrictions. On Mon, 4 Aug 2008, Jim Redman wrote: > Has there been any work/would it be possible, to layer a javacomm > look-alike on top of the GNU code? > > The goal is not to move the javax code forward, but to emulate the > "legacy" javax packages for people who still need this. > > Jim > > Trent Jarvi wrote: >> >> It would be nice to work with Sun to resolve those longstanding issues. >> But it may not be practical unless the process goes as fast and painless >> as the grandfathering of commapi did. >> >> Another option may be the old kaffe extensions that moved to gnu >> classpathx. These don't have the native libraries but should provide >> the 2.0 interface and the javax.comm.properties mechansim for SPI. >> >> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From florianmanschwetus at gmx.de Tue Aug 5 05:04:46 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 13:04:46 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: References: <48971C1F.9020806@gmx.de> Message-ID: <489833CE.1040801@gmx.de> Just look at sendCommand in this method I have to place a Thread.sleep(20) after each byte send to get working. Even the event based receive doesn't work fine but this could be may stupidness. The specifikation document (it is on the last pages of the manual) for the beamer could be found on: http://www.optoma.co.uk/support.aspx Florian Manschwetus Trent Jarvi schrieb: > > Hi Florian > > Sorry for the top post in advance. I worry you may not see my answer > under all your code :) > > I have not received this email before. This is 500k of code which I > don't have time to read. I can spend about 5 min on each hobby email > and still get to work in the morning. I have a couple suggestions for > how to get an answer. > > First, cut out your comments and extra code so you can demonstrate the > question (I might even glance and see what is wrong then). Don't go for > a working final product. Isolate the problem using a simple program and > then ask with that as an example. If I did what you just did, I'd have > to post 3/4 of a million lines of code :) > > Second, join the rxtx mail-list and ask there. This will give you 100x > more eyes. I'll also read and try to follow. > > -- > taj > > > > On Mon, 4 Aug 2008, Florian Manschwetus wrote: > >> It could be that my university account is blocked by filters so >> resending from here. >> >> >> Topic is to control Optoma HD80 beamer using rs232 serial chat. >> This code is able to detect power state and switch the beamer on / off. >> connected is the beamer using a digitus usb 2.0 serial adapter with an >> FT232 USB-Serial adapter the systems architecture is amd64. >> >> Please take a look in the sendCommand routine i have to place theire >> those Thread.sleep to get it working. >> Now the question is this correct or is there a better way to get this >> working correctly? >> >> In the javadoc coming with the install i found this: >> setBaudBase >> >> public boolean setBaudBase(int BaudBase) >> throws UnsupportedCommOperationException, >> java.io.IOException >> >> Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 >> before using. >> >> could this explain the error? >> I attached my java source and the protocol description for the beamer >> (available on vendor website). >> >> thx, >> Florian Manschwetus >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: TestRS232.java Type: text/x-java Size: 9143 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0086.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0087.bin From michael.erskine at ketech.com Tue Aug 5 05:53:49 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Tue, 5 Aug 2008 12:53:49 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489833CE.1040801@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> > Just look at sendCommand in this method I have to place a > Thread.sleep(20) after each byte send to get working. Even the event > based receive doesn't work fine but this could be may stupidness. Hi Florian, Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. Regards, Michael Erskine. From florianmanschwetus at gmx.de Tue Aug 5 07:28:15 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:28:15 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> Message-ID: <4898556F.8000208@gmx.de> Michael Erskine schrieb: >> Just look at sendCommand in this method I have to place a >> Thread.sleep(20) after each byte send to get working. Even the event >> based receive doesn't work fine but this could be may stupidness. > > Hi Florian, > > Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. > > Regards, > Michael Erskine. > Ok, sounds fine for the receiving problem. But why i have to wait after each byte when sending a command squence? (the for loop in send command) Florian > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/284f350c/attachment-0042.bin From florianmanschwetus at gmx.de Tue Aug 5 07:44:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:44:14 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <4898592E.2020908@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >>> Just look at sendCommand in this method I have to place a >>> Thread.sleep(20) after each byte send to get working. Even the event >>> based receive doesn't work fine but this could be may stupidness. >> >> Hi Florian, >> >> Yes, naturally you'll have to wait for a response from the other end. >> Why not wait for notification from the event thread perhaps using a >> BlockingDeque rather than your LinkedList. Generally I >> try to decouple all input and output streams: in your case your >> application is operating synchronously like the "expect" program >> (http://expect.nist.gov/) so waits (or timeouts) will need to be >> factored in. >> >> Regards, >> Michael Erskine. >> > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) > > Florian Furthermore there is this basic baud with this confusing javadoc entry: public boolean setBaudBase(int BaudBase) throws UnsupportedCommOperationException, java.io.IOException Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 before using. maybe this could explain something Florian >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/006c7425/attachment-0042.bin From jredman at ergotech.com Tue Aug 5 09:13:36 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 05 Aug 2008 09:13:36 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: Message-ID: <48986E20.3060104@ergotech.com> Trent, So two issues: 1) Technically I'm still not sure how easy/practical a layer would be. The problems are always classes like listeners, and wrapping returns of gnu.io classes. I really see it as a "delegate" type of concept. Any thoughts or ideas of the practicality of this approach? The idea is not to modify RXTX. 2) Javax. The javax namespace does seem to be in widespread use outside of Sun (the same is true for the java namespace). The classpath extensions, or some other location, should be interested in a JavaComm implementation even if it does have dependencies on RXTX. Would you have any philosophical objection to an approach like that? Of course, I suspect it might be better if someone with that authority at Sun would admit that the javax namespace is already in the wild and that there is no problem with it being used within RXTX. Jim Trent Jarvi wrote: > Hi Jim, > > I will not step into the javax.comm namespace without Sun's explicite > permission. I fully understand the pain point you are trying to address. > > In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm > Linux) - which remains an integral part of rxtx. At the time it was a win for > Sun and rxtx. > > The Sun commapi license is/was fairly clear that rxtx should not step into that > namespace. It made sense as Sun was active in that space and rxtx may go into > another namespace - it was an experiment in working with Sun. > > This may sound silly looking at something that happened almost 10 years ago. > In a community of respect which Sun helped create, there is no question about > what to do. I hope eventually Sun will step up and do a right thing too. > > I agree that this is hurting the API more than helping it. There are also > questions about how to replace the API in the long term which includes HID > support which isn't going well so far. > > Others that can't even look at Sun's javax.comm today and can look at Kaffe's > contribution to classpathx can easily work around such restrictions. > > On Mon, 4 Aug 2008, Jim Redman wrote: > >> Has there been any work/would it be possible, to layer a javacomm >> look-alike on top of the GNU code? >> >> The goal is not to move the javax code forward, but to emulate the >> "legacy" javax packages for people who still need this. >> >> Jim >> >> Trent Jarvi wrote: >>> It would be nice to work with Sun to resolve those longstanding issues. >>> But it may not be practical unless the process goes as fast and painless >>> as the grandfathering of commapi did. >>> >>> Another option may be the old kaffe extensions that moved to gnu >>> classpathx. These don't have the native libraries but should provide >>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>> >>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From sandeep at genevasoftech.com Tue Aug 5 11:18:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Tue, 05 Aug 2008 22:48:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <48988B6C.5080409@genevasoftech.com> Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. *-- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/ad20f1cb/attachment-0042.html From Martin.Oberhuber at windriver.com Tue Aug 5 13:30:17 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Tue, 5 Aug 2008 21:30:17 +0200 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Sandeep, shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on Sol7 but I've successfully run it on Sol9 and Sol10. Or is your request really about a native 64bit variant? I'm afraid that then you're out of luck since I think that quite a bit of RXTX is not yet ready for 64 bit. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Sandeep Kumar K Sent: Tuesday, August 05, 2008 7:19 PM To: rxtx at qbang.org Subject: [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so for Solaris 9 Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. -- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/81b7f988/attachment-0042.html From tjarvi at qbang.org Tue Aug 5 22:38:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 22:38:34 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 5 Aug 2008, Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built > on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid that > then > you're out of luck since I think that quite a bit of RXTX is not yet > ready > for 64 bit. > While rxtx-2.1-7 probably has problems, The CVS code should be OK for 64 bit Solaris. If it isn't, let me know and I'll find which patch is missing. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Aug 5 23:13:00 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 23:13:00 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48986E20.3060104@ergotech.com> References: <48986E20.3060104@ergotech.com> Message-ID: On Tue, 5 Aug 2008, Jim Redman wrote: > Trent, > > So two issues: > > 1) Technically I'm still not sure how easy/practical a layer would be. The > problems are always classes like listeners, and wrapping returns of gnu.io > classes. I really see it as a "delegate" type of concept. Any thoughts or > ideas of the practicality of this approach? The idea is not to modify RXTX. I have not put too much thought into this. I assume you want what rxtx 2.0 provided to tie into javax.comm implementations. More classes could be added to rxtx 2.1-7 for SPI support. Maintaining rxtx-2.0 could also be handed to someone if they like. > > 2) Javax. The javax namespace does seem to be in widespread use outside of > Sun (the same is true for the java namespace). The classpath extensions, or > some other location, should be interested in a JavaComm implementation even > if it does have dependencies on RXTX. Would you have any philosophical > objection to an approach like that? > No problems. Classpathx would be a possible place to do it. I'd suggest thinking twice about what this involves in practical terms. You would be wanting to revive the 2.0 API while Sun is at 3.0 and grandfathering the JSR. This undermines the main reason (established api) for using the javax.comm namespace and does not leave such a project in a good position. The only win I see here is maintaining support for applications that can't migrate namespaces. Not that that isn't important. At some point it is going to be less work to just edit the bytecode :) Such a javax.comm effort would also be signing up new projects that decided to use the work up for concerns they probably will not understand or expect. That probably isn't a good path to facilitate for new projects at this time. We will put a good faith effort to work well with others but keep in mind the project has limited bandwidth for such efforts. > Of course, I suspect it might be better if someone with that authority at Sun > would admit that the javax namespace is already in the wild and that there is > no problem with it being used within RXTX. > > Jim > > Trent Jarvi wrote: >> Hi Jim, >> >> I will not step into the javax.comm namespace without Sun's explicite >> permission. I fully understand the pain point you are trying to address. >> >> In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java >> Comm Linux) - which remains an integral part of rxtx. At the time it was a >> win for Sun and rxtx. >> >> The Sun commapi license is/was fairly clear that rxtx should not step into >> that namespace. It made sense as Sun was active in that space and rxtx may >> go into another namespace - it was an experiment in working with Sun. >> >> This may sound silly looking at something that happened almost 10 years >> ago. In a community of respect which Sun helped create, there is no >> question about what to do. I hope eventually Sun will step up and do a >> right thing too. >> >> I agree that this is hurting the API more than helping it. There are also >> questions about how to replace the API in the long term which includes HID >> support which isn't going well so far. >> >> Others that can't even look at Sun's javax.comm today and can look at >> Kaffe's contribution to classpathx can easily work around such >> restrictions. >> >> On Mon, 4 Aug 2008, Jim Redman wrote: >> >>> Has there been any work/would it be possible, to layer a javacomm >>> look-alike on top of the GNU code? >>> >>> The goal is not to move the javax code forward, but to emulate the >>> "legacy" javax packages for people who still need this. >>> >>> Jim >>> >>> Trent Jarvi wrote: >>>> It would be nice to work with Sun to resolve those longstanding issues. >>>> But it may not be practical unless the process goes as fast and painless >>>> as the grandfathering of commapi did. >>>> >>>> Another option may be the old kaffe extensions that moved to gnu >>>> classpathx. These don't have the native libraries but should provide >>>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>>> >>>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From sandeep at genevasoftech.com Wed Aug 6 00:03:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Wed, 06 Aug 2008 11:33:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: <48993EB8.30107@genevasoftech.com> Thank you Mr. Martin for your suggestion. The native file which is given in rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am getting the following error . Any suggestions to solve this issue. I am using Solaris SPARC 64 bit machine. ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) thrown while loading gnu.io.RXTXCommDriver Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(Unknown Source) at java.lang.ClassLoader.loadLibrary(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) at com.ReadFromModem.main(ReadFromModem.java:84) * * *Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid > that then > you're out of luck since I think that quite a bit of RXTX is not yet ready > for 64 bit. > > Cheers, > -- > *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > ------------------------------------------------------------------------ > *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On > Behalf Of *Sandeep Kumar K > *Sent:* Tuesday, August 05, 2008 7:19 PM > *To:* rxtx at qbang.org > *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so > for Solaris 9 > > Hi, > > Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 > bit machine. The librxtxSerial.so given in website is for Solaris 8. > > *-- > > Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/1e920343/attachment-0042.html From tjarvi at qbang.org Wed Aug 6 00:21:42 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 00:21:42 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <48993EB8.30107@genevasoftech.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> <48993EB8.30107@genevasoftech.com> Message-ID: Hi Sandeep You may be out of luck unless you can compile the 2.1 src in CVS (requires gnu make and gcc). But you could try the ToyBox(R)(TM) which is a collection of WiLdLy untested cross compiled 2.1-7 binaries covering everything from the ibm z series to embeded arm/ppc. To give an idea how poorly these are tested, I don't even know if z series machines have a serial port. ftp://www.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Solaris They should at least match the binary types. Actually, I think if you use the rxtx jar from CVS with that file, it should 'work' as the fix for 64 bits was in java not the native code. You could just cd rxtx*/src; javac *.java then jar -cf RXTXcomm.jar `find -name \*.class` to create the hybrid which will complain about version information a bit. On Wed, 6 Aug 2008, Sandeep Kumar K wrote: > Thank you Mr. Martin for your suggestion. The native file which is given in > rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am > getting the following error . > Any suggestions to solve this issue. > I am using Solaris SPARC 64 bit machine. > > ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar > java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 > (Possible cause: architecture word > width mismatch) thrown while loading gnu.io.RXTXCommDriver > Exception in thread "main" java.lang.UnsatisfiedLinkError: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF > class: ELFCLASS64 (Possible cause: > architecture word width mismatch) > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(Unknown Source) > at java.lang.ClassLoader.loadLibrary(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > at com.ReadFromModem.main(ReadFromModem.java:84) > > * > * > > *Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > > > Oberhuber, Martin wrote: >> Sandeep, >> shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse >> variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on >> Sol7 but I've successfully run it on Sol9 and Sol10. >> Or is your request really about a native 64bit variant? I'm afraid that >> then >> you're out of luck since I think that quite a bit of RXTX is not yet ready >> for 64 bit. >> Cheers, >> -- >> *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> ------------------------------------------------------------------------ >> *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On >> Behalf Of *Sandeep Kumar K >> *Sent:* Tuesday, August 05, 2008 7:19 PM >> *To:* rxtx at qbang.org >> *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so >> for Solaris 9 >> >> Hi, >> >> Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 >> bit machine. The librxtxSerial.so given in website is for Solaris 8. >> >> *-- >> Thanks & Regards >> >> Sandeep Kumar K >> Sr. Software Engineer >> Geneva Software Technologies >> Whitefield, Bangalore >> Mob : 9880193454* >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> From michael.erskine at ketech.com Wed Aug 6 01:39:28 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 6 Aug 2008 08:39:28 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Florian Manschwetus wrote: > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) Hi Florian, I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. Regards, Michael Erskine. From florianmanschwetus at gmx.de Wed Aug 6 02:53:16 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 06 Aug 2008 10:53:16 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Message-ID: <4899667C.6010706@gmx.de> Michael Erskine schrieb: > Florian Manschwetus wrote: >> Ok, sounds fine for the receiving problem. >> But why i have to wait after each byte when sending a command squence? >> (the for loop in send command) > > Hi Florian, > I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. > > Regards, > Michael Erskine. > correct with a terminal on the other end it works, my idea was that this basic baud has some influence. Could some one explain what it is for? Florian > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/c2b4fa84/attachment-0042.bin From rick_knight at rlknight.com Wed Aug 6 13:01:07 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:01:07 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F4F3.3020707@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > I have an application (Readerware) that uses RXTX with Javax to access the serial port. This used to work fine under previous Linux' and Java, but something has changed, I assume with Java itself , that is causing the application to fail with a link error. The application is not able to find librxtxSerialParallel.so. RXTX supplies librxtxSerial.so and librxtxParallel.so, but not librxtxSerialParallel.so. Where can I get librxtxSerialParallel.so, or do I need it? Is something else causing the lib to not be found? Thanks, Rick Knight From rick_knight at rlknight.com Wed Aug 6 13:17:55 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:17:55 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F8E3.5060400@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Thanks for the reply. The developer of the app I'm trying to use (Readerware) has sent me a copy of the comm.api and I've copied the library (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar into the proper places. When I try to run the application, I get this error... Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: /usr/lib/libSolarisSerialParallel.so: /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not little-endian (Possible cause: endianness mismatch) Caught java.lang.UnsatisfiedLinkError: com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I while loading driver com.sun.comm.SolarisDriver Is there a way around this error? Thanks again, Rick Knight From jlar310 at gmail.com Wed Aug 6 13:37:42 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 14:37:42 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899F8E3.5060400@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > The developer of the app I'm trying to use (Readerware) has sent me a > copy of the comm.api and I've copied the library > (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar > into the proper places. When I try to run the application, I get this > error... > > Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: > /usr/lib/libSolarisSerialParallel.so: > /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not > little-endian (Possible cause: endianness mismatch) > Caught java.lang.UnsatisfiedLinkError: > com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I > > while loading driver com.sun.comm.SolarisDriver > > Is there a way around this error? What host OS are you running? From your original post it looks like 32 bit Linux. The libSolarisSerialParallel.so file is for Sun Solaris and will vary depending on the underlying hardware architecture as well. Sorry for the double post Rick, but I failed to send this to the list the first time... -- Jeff From rick_knight at rlknight.com Wed Aug 6 13:44:29 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:44:29 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: <4899FF1D.9030504@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > > >> The developer of the app I'm trying to use (Readerware) has sent me a >> copy of the comm.api and I've copied the library >> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >> into the proper places. When I try to run the application, I get this >> error... >> >> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >> /usr/lib/libSolarisSerialParallel.so: >> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >> little-endian (Possible cause: endianness mismatch) >> Caught java.lang.UnsatisfiedLinkError: >> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >> >> while loading driver com.sun.comm.SolarisDriver >> >> Is there a way around this error? >> > > What host OS are you running? From your original post it looks like 32 > bit Linux. > > The libSolarisSerialParallel.so file is for Sun Solaris and will vary > depending on the underlying hardware architecture as well. > > I'm running Kubuntu Linux (debian based). It's 32 bit. Rick Knight From jlar310 at gmail.com Wed Aug 6 15:33:23 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 16:33:23 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > I don't think Sun did binary libraries for Linux in the 2.0 version. Can someone with more historical experience than I confirm that? I recently tried to port a Comm API application from Solaris sparc to Linux x86 and likewise could not get my hands on the binary libraries. I eventually just re-wrote the code to use the gnu namespace packages and rxtx 2.1. What I don't understand is why your application vendor does not provide everything you need to run their software. FYI: I have librxtxParallel.so and librxtxSerial.so installed at JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is /usr/java/default which is actually a softlink to /usr/java/jre1.6.0_05. -- Jeff From defiantlew at yahoo.com.au Wed Aug 6 16:29:33 2008 From: defiantlew at yahoo.com.au (Lew L) Date: Thu, 7 Aug 2008 08:29:33 +1000 Subject: [Rxtx] Sun's Comm API Documentation References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> Message-ID: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> As a matter of interest is the Sun Comm API documentation available somewhere? I have tried the Sun site but it seems to have been removed. Unless I have missed the documentation for RXTX? I javadocced the RXTX source but information (to me) is minimal. Somewhere I got the impression that the Sun Comm API docs is, or was, compatible with RXTX, what is the best docs to use in conjuntion with RXTX and where may the be available? Cheers Lew From rick_knight at rlknight.com Wed Aug 6 17:18:33 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:18:33 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A3149.4050306@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff I'm not sure if I posted this here or not, but when I try to build RXTX from source I get this install error... make all-am make[1]: Entering directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' make[1]: Nothing to be done for `all-am'. make[1]: Leaving directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 Can you tell me how to get past this error and get RXTX built and installed? Thanks, Rick From bboyes at systronix.com Wed Aug 6 17:40:12 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Wed, 06 Aug 2008 17:40:12 -0600 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: At 16:29 08/06/2008, Lew L wrote: >As a matter of interest is the Sun Comm API documentation available >somewhere? I have tried the Sun site but it seems to have been removed. It's in the file we have posted, link in prev email (sorry, in a huge hurry right now). Javadocs definitely there. >Unless I have missed the documentation for RXTX? I javadocced the RXTX >source but information (to me) is minimal. >Somewhere I got the impression that the Sun Comm API docs is, or was, >compatible with RXTX, what is the best docs to use in conjuntion with RXTX >and where may the be available? Yeah, this is one of my concerns/beefs. There is little documentation for RXTX and it isn't just the same as javaxcomm. I would be willing to help out writing docs for RXTX! Yes really... esp if we can fix the Bluetooth issues. best regards Bruce >Cheers >Lew > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx ------- WWW.SYSTRONIX.COM ---------- Real embedded Java and much more +1-801-534-1017 Salt Lake City, USA From rick_knight at rlknight.com Wed Aug 6 17:54:08 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:54:08 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A39A0.2090309@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff, I would like for my vendor to switch to rxtx 2.1. It would make things much easier for me. I'm not sure why he's still using the javax compatible code. He's a small operation. Re-writing the code to use gnu namespace sounds like a major overhaul. Was it? Thanks, Rick From tjarvi at qbang.org Wed Aug 6 21:35:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:35:12 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: >> >>> Jeff wrote: >>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>>> >>>> >>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things > much easier for me. I'm not sure why he's still using the javax > compatible code. He's a small operation. Re-writing the code to use gnu > namespace sounds like a major overhaul. Was it? > Hi Jeff, The changes are fairly mechanical. Imports need to change and any explicite use of the namespace needs to change such as catching an exception. The following script was made for maintaining rxtx 2.0 but can apply to other needs. It is in the contrib dir with rxtx source. #!/bin/sh # Don't use! :) # # Sat, 03 May 2003 16:45:08 Modifications from J?rg Weule # Create a ed-cmd for the change of one pattern # case $1 in gnu) X=g/javax_comm/s+javax_comm+gnu_io+g ;; javax) X=g/gnu_io/s+gnu_io+javax_comm+g ;; *) echo;echo;echo From the top rxtx directory run;echo;echo -e \\t./ChangePackage.sh gnu;echo -e \\t\\tor;echo -e \\t./ChangePackage.sh javax;echo;echo; exit 0 ;; esac # # ed will be used to keep the owner and mode of the files unchanged. # We have run the ed-script for the characters '.' '/' as well. # "tr _ $D" do the change. # find . -type f -a -print | grep -v $0 | (while read F ; do ( echo $X; echo $X| tr _ /; echo $X| tr _ .; echo w; echo q ) | ed $F 2>&1 >/dev/null done ) # # Now we do little changes at the Makefiles. Hope that all we need. # find . -name Makefile\* -a -print | (while read F ; do cat < References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: On Thu, 7 Aug 2008, Lew L wrote: > As a matter of interest is the Sun Comm API documentation available > somewhere? I have tried the Sun site but it seems to have been removed. > > Unless I have missed the documentation for RXTX? I javadocced the RXTX > source but information (to me) is minimal. > Somewhere I got the impression that the Sun Comm API docs is, or was, > compatible with RXTX, what is the best docs to use in conjuntion with RXTX > and where may the be available? > Hi Lew, The documentation on Sun's website is accurate. The changes that are problematic in 3.0 are on the backside which rxtx used to plug into. http://java.sun.com/products/javacomm/reference/api/index.html CommPortIdentifier may have some minor differences (judging by the authors notes). -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Aug 6 21:46:08 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:46:08 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > If javax.comm.properties is properly installed and you are using a 2.0 version of Sun's commapi with rxtx 2.0, you should not see the library attempt to load libSolarisSerialParallel.so. Sun CommAPI 3.0 will not work with any version of rxtx as it is hard coded to use the shared library. See the INSTALL file with rxtx-2.0 source for more help with the properties file. -- Trent Jarvi tjarvi at qbang.org From jlar310 at gmail.com Thu Aug 7 06:32:06 2008 From: jlar310 at gmail.com (Jeff) Date: Thu, 7 Aug 2008 07:32:06 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > Jeff wrote: >> >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >> wrote: >> >>> >>> Jeff wrote: >>> >>>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>> wrote: >>>> >>>> >>>> >>>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things much > easier for me. I'm not sure why he's still using the javax compatible code. > He's a small operation. Re-writing the code to use gnu namespace sounds like > a major overhaul. Was it? I found it quite easy. In fact, in order to accommodate the transition, I actually separated all of the code that deals directly with the Comm API or RXTX into a helper class. The helper class was then coded to use reflection to determine which library was available and then instantiate the necessary objects. No direct imports of either library are used. The main application just needs to get it's hands on the IO streams and need not deal directly with the libraries. Other programs may not be so simple... But this doesn't really help you unless your vendor forks over the source code... -- Jeff From rick_knight at rlknight.com Thu Aug 7 09:47:12 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Thu, 07 Aug 2008 08:47:12 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: <489B1900.10108@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >>> wrote: >>> >>> >>>> Jeff wrote: >>>> >>>> >>>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>>> copy of the comm.api and I've copied the library >>>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>>> into the proper places. When I try to run the application, I get this >>>>>> error... >>>>>> >>>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>>> /usr/lib/libSolarisSerialParallel.so: >>>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>>> little-endian (Possible cause: endianness mismatch) >>>>>> Caught java.lang.UnsatisfiedLinkError: >>>>>> >>>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>>> >>>>>> while loading driver com.sun.comm.SolarisDriver >>>>>> >>>>>> Is there a way around this error? >>>>>> >>>>>> >>>>>> >>>>> What host OS are you running? From your original post it looks like 32 >>>>> bit Linux. >>>>> >>>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>>> depending on the underlying hardware architecture as well. >>>>> >>>>> >>>>> >>>>> >>>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>>> >>>> >>>> >>> I don't think Sun did binary libraries for Linux in the 2.0 version. >>> Can someone with more historical experience than I confirm that? >>> >>> I recently tried to port a Comm API application from Solaris sparc to >>> Linux x86 and likewise could not get my hands on the binary libraries. >>> I eventually just re-wrote the code to use the gnu namespace packages >>> and rxtx 2.1. >>> >>> What I don't understand is why your application vendor does not >>> provide everything you need to run their software. >>> >>> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >>> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >>> /usr/java/default which is actually a softlink to >>> /usr/java/jre1.6.0_05. >>> >>> >>> >> Jeff, >> >> I would like for my vendor to switch to rxtx 2.1. It would make things much >> easier for me. I'm not sure why he's still using the javax compatible code. >> He's a small operation. Re-writing the code to use gnu namespace sounds like >> a major overhaul. Was it? >> > > I found it quite easy. In fact, in order to accommodate the > transition, I actually separated all of the code that deals directly > with the Comm API or RXTX into a helper class. The helper class was > then coded to use reflection to determine which library was available > and then instantiate the necessary objects. No direct imports of > either library are used. The main application just needs to get it's > hands on the IO streams and need not deal directly with the libraries. > Other programs may not be so simple... > > But this doesn't really help you unless your vendor forks over the > source code... > > Jeff, This may not help me directly, but I'm going to forward this thread to the vendor. I think he'll be open to making things work. Thanks again, Rick Knight From agusmunioz at gmail.com Thu Aug 7 16:39:51 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Thu, 7 Aug 2008 19:39:51 -0300 Subject: [Rxtx] How to send ack? Message-ID: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Hi, I'm still learning about serial communication and I have some doubts. I've got this question about how to do the following thing in rxtx. I have this hardware that connect to a PC using a serial port. These hardware receives data from a telephone line, proccess it, and then send it forward to the serial port. I've used a program named wincomm that shows what information is send it through the serial port and I have the nex behaviour: The hardware has a buffer where all data is stored, that cannot be sent it through the seria port. The program reads the first data send it by the hardware, and keep reading the same data always. There is a button in the application that says enable Ack, and when I click, then the hardware start to send all the stored information, and all the information is shown. I write a class, using rxtx that reads the serial port, and the same thing happens, it remains reading the same (first) data all the time. And I thing something like the enable Ack I'm missing. How can I do this enable Ack from my java code using rxtx? Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080807/e0a0f9a1/attachment-0040.html From ajmas at sympatico.ca Thu Aug 7 18:26:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 7 Aug 2008 20:26:41 -0400 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: <4BF42297-81E2-4BB8-A89F-1D43588379AE@sympatico.ca> On 6-Aug-08, at 19:40 , Bruce Boyes wrote: >> Unless I have missed the documentation for RXTX? I javadocced the >> RXTX >> source but information (to me) is minimal. >> Somewhere I got the impression that the Sun Comm API docs is, or was, >> compatible with RXTX, what is the best docs to use in conjuntion >> with RXTX >> and where may the be available? > > Yeah, this is one of my concerns/beefs. There is little documentation > for RXTX and it isn't just the same as javaxcomm. > > I would be willing to help out writing docs for RXTX! Yes really... > esp if we can fix the Bluetooth issues. If you want to contribute documentation then the best place to do that is the wiki. If there is anything missing or that could be improved on then please do so. If there are any points that you would like to see improved, for which you don't have the knowledge then ask on the mailing list for a volunteer. Andre From florianmanschwetus at gmx.de Fri Aug 8 03:04:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Fri, 08 Aug 2008 11:04:14 +0200 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Message-ID: <489C0C0E.2020401@gmx.de> Agustin Mu?oz schrieb: > Hi, I'm still learning about serial communication and I have some > doubts. I've got this question about how to do the following thing in rxtx. > I have this hardware that connect to a PC using a serial port. These > hardware receives data from a telephone line, proccess it, and then send > it forward to the serial port. I've used a program named wincomm that > shows what information is send it through the serial port and I have the > nex behaviour: > > The hardware has a buffer where all data is stored, that cannot be sent > it through the seria port. > The program reads the first data send it by the hardware, and keep > reading the same data always. > There is a button in the application that says enable Ack, and when I > click, then the hardware start to send all the stored information, and > all the information is shown. > > I write a class, using rxtx that reads the serial port, and the same > thing happens, it remains reading the same (first) data all the time. > And I thing something like the enable Ack I'm missing. > How can I do this enable Ack from my java code using rxtx? Afaik, a look at man ascii reveals: Okt Dez Hex Char 006 6 06 ACK So, i hope this will do the job: send(6); florian > > Thanks in advance > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/5b4965f8/attachment-0040.bin From agusmunioz at gmail.com Fri Aug 8 16:31:00 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 19:31:00 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <489C0C0E.2020401@gmx.de> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> Message-ID: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Hi Florian, thanks for the answer. By send(6) you mean to get the port OutputStream and write a 6? I try that but it didn't work. Any suggestion? Thanks On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < florianmanschwetus at gmx.de> wrote: > Agustin Mu?oz schrieb: > > Hi, I'm still learning about serial communication and I have some doubts. >> I've got this question about how to do the following thing in rxtx. >> I have this hardware that connect to a PC using a serial port. These >> hardware receives data from a telephone line, proccess it, and then send it >> forward to the serial port. I've used a program named wincomm that shows >> what information is send it through the serial port and I have the nex >> behaviour: >> >> The hardware has a buffer where all data is stored, that cannot be sent >> it through the seria port. >> The program reads the first data send it by the hardware, and keep reading >> the same data always. >> There is a button in the application that says enable Ack, and when I >> click, then the hardware start to send all the stored information, and all >> the information is shown. >> >> I write a class, using rxtx that reads the serial port, and the same thing >> happens, it remains reading the same (first) data all the time. And I thing >> something like the enable Ack I'm missing. >> How can I do this enable Ack from my java code using rxtx? >> > Afaik, a look at man ascii reveals: > Okt Dez Hex Char > 006 6 06 ACK > So, i hope this will do the job: > send(6); > > florian > >> >> Thanks in advance >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/7f3fba42/attachment-0039.html From agusmunioz at gmail.com Fri Aug 8 18:39:27 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 21:39:27 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Message-ID: <988288430808081739x7f9e7889id82591d5a9e2b4f6@mail.gmail.com> Ok, Florian, it works!! my problem was that I've been sending, through the OutputStream, the bytes of 6 as a string: out.write("6".getBytes()); but then I realized that you can write an int on an OuptuStream, so I tried that and It works: out.write(6); Thank you for the guidance!! On Fri, Aug 8, 2008 at 7:31 PM, Agustin Mu?oz wrote: > Hi Florian, thanks for the answer. By send(6) you mean to get the port > OutputStream and write a 6? > > I try that but it didn't work. > > Any suggestion? > > Thanks > > > On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < > florianmanschwetus at gmx.de> wrote: > >> Agustin Mu?oz schrieb: >> >> Hi, I'm still learning about serial communication and I have some doubts. >>> I've got this question about how to do the following thing in rxtx. >>> I have this hardware that connect to a PC using a serial port. These >>> hardware receives data from a telephone line, proccess it, and then send it >>> forward to the serial port. I've used a program named wincomm that shows >>> what information is send it through the serial port and I have the nex >>> behaviour: >>> >>> The hardware has a buffer where all data is stored, that cannot be sent >>> it through the seria port. >>> The program reads the first data send it by the hardware, and keep >>> reading the same data always. >>> There is a button in the application that says enable Ack, and when I >>> click, then the hardware start to send all the stored information, and all >>> the information is shown. >>> >>> I write a class, using rxtx that reads the serial port, and the same >>> thing happens, it remains reading the same (first) data all the time. And I >>> thing something like the enable Ack I'm missing. >>> How can I do this enable Ack from my java code using rxtx? >>> >> Afaik, a look at man ascii reveals: >> Okt Dez Hex Char >> 006 6 06 ACK >> So, i hope this will do the job: >> send(6); >> >> florian >> >>> >>> Thanks in advance >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/b918ab3d/attachment-0039.html From florianmanschwetus at gmx.de Sat Aug 9 00:45:43 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Sat, 09 Aug 2008 08:45:43 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4899667C.6010706@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> Message-ID: <489D3D17.9090209@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >> Florian Manschwetus wrote: >>> Ok, sounds fine for the receiving problem. >>> But why i have to wait after each byte when sending a command squence? >>> (the for loop in send command) >> >> Hi Florian, >> I'd imagine you probably don't! You could send all bytes in one go and >> RXTX would send them. The problem is most probably the other end: >> perhaps it has a really small buffer, some non-standard UART, or a >> crazy timing issue. If you attach a terminal to your output and send >> all the bytes of a command in one go they should appear no problem. >> >> Regards, >> Michael Erskine. >> > correct with a terminal on the other end it works, my idea was that this > basic baud has some influence. Could some one explain what it is for? > > Florian To make it more clear, my problem is that i can't use: outputStream.write(byte[]); => Beamer doesn't understand the sequence. (mostly no answer when he answers then *001) when i use this construct instead: for (int i = 0; i < command.length; i++) { this.outputStream.write(command[i]); try { Thread.sleep(25); } catch (InterruptedException e) { // TODO Auto-generated catch block e.printStackTrace(); } } it works nearly reliable. So what could it be? This Basic Baud is what exactly? Florian -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080809/692304ee/attachment-0039.bin From tjarvi at qbang.org Sat Aug 9 16:37:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Aug 2008 16:37:19 -0600 (MDT) Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489D3D17.9090209@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> <489D3D17.9090209@gmx.de> Message-ID: On Sat, 9 Aug 2008, Florian Manschwetus wrote: > Florian Manschwetus schrieb: >> Michael Erskine schrieb: >>> Florian Manschwetus wrote: >>>> Ok, sounds fine for the receiving problem. >>>> But why i have to wait after each byte when sending a command squence? >>>> (the for loop in send command) >>> >>> Hi Florian, >>> I'd imagine you probably don't! You could send all bytes in one go and >>> RXTX would send them. The problem is most probably the other end: perhaps >>> it has a really small buffer, some non-standard UART, or a crazy timing >>> issue. If you attach a terminal to your output and send all the bytes of a >>> command in one go they should appear no problem. >>> >>> Regards, >>> Michael Erskine. >>> >> correct with a terminal on the other end it works, my idea was that this >> basic baud has some influence. Could some one explain what it is for? >> >> Florian > To make it more clear, > my problem is that i can't use: > outputStream.write(byte[]); > => Beamer doesn't understand the sequence. (mostly no answer when he answers > then *001) > > when i use this construct instead: > > for (int i = 0; i < command.length; i++) { > this.outputStream.write(command[i]); > try { > Thread.sleep(25); > } catch (InterruptedException e) { > // TODO Auto-generated catch block > e.printStackTrace(); > } > } > > it works nearly reliable. > > So what could it be? This Basic Baud is what exactly? > I suspect you are using the 'moon protocol' and don't know it. RXTX enables this by default. The buffer on the other end is first in first out while reading. If the buffer is full, the bits are hand carried to the moon and burried. Then if the other side reads a couple bytes, two more bytes go into the buffer followed by more moon protocol. The resulting array of bytes the other side reads may appear to be scrambled until you go to the moon, get the bits and insert them in the right place. Flow control can prevent the default moon protocol and throttles the communiation by almost writing a byte at a time as need be. Hardware flow control is preferable but software flow control should also work. Read and write can appear to hang if the other side is not connected. This is why we don't enable them all the time. If you can't use flow control, you have to take care with the moon protocol and give the other side time to read. That is what your slower version of write is doing. -- Trent Jarvi tjarvi at qbang.org From rxtx at allenjb.me.uk Mon Aug 11 08:06:36 2008 From: rxtx at allenjb.me.uk (AllenJB) Date: Mon, 11 Aug 2008 15:06:36 +0100 Subject: [Rxtx] Disabling EV_RXFLAG Message-ID: <48A0476C.2090800@allenjb.me.uk> Hi all, I'm working with a device which does not use an EvtChar and need to disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an event mask of FD 01 00 00. The reference software I have uses FB 00 00 00. With the rxtx mask I get framing errors which I believe are caused when the EvtChar is received. Is there currently a way with rxtx (I've using rxtx from Java) to disable EV_RXFLAG? If not from Java, where would I start if I wanted to turn the EV_RXFLAG option off in the C code? I've had a grep of the rxtx source code, but I can't see where EV_RXFLAG is being set. Thanks in advance, AllenJB From tjarvi at qbang.org Mon Aug 11 14:17:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Aug 2008 14:17:27 -0600 (MDT) Subject: [Rxtx] Disabling EV_RXFLAG In-Reply-To: <48A0476C.2090800@allenjb.me.uk> References: <48A0476C.2090800@allenjb.me.uk> Message-ID: On Mon, 11 Aug 2008, AllenJB wrote: > Hi all, > > I'm working with a device which does not use an EvtChar and need to > disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an > event mask of FD 01 00 00. The reference software I have uses FB 00 00 > 00. With the rxtx mask I get framing errors which I believe are caused > when the EvtChar is received. > > Is there currently a way with rxtx (I've using rxtx from Java) to > disable EV_RXFLAG? > > If not from Java, where would I start if I wanted to turn the EV_RXFLAG > option off in the C code? I've had a grep of the rxtx source code, but I > can't see where EV_RXFLAG is being set. > > Thanks in advance, > > AllenJB Hi Allen, I'd look at termios.c::tcsetattr() and termios.c::FillDCB() -- Trent Jarvi tjarvi at qbang.org From superdadusa at gmail.com Tue Aug 12 13:57:32 2008 From: superdadusa at gmail.com (John Choi) Date: Tue, 12 Aug 2008 13:57:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. Message-ID: Hi all, Just let you all know I just start to learn Java. I have download the serial comm package and the source code from open source communities.. I was able to verify with the given message string via serial monitor. when the given message string sends to the serial port then the character return added to the end of string by default if I use "Hello World" however if I changed to something else other than "Hello, World" there is no character return add to the end of string. I thing the library download from rxtx.org has implemented for the special strings. I can do like "login\n" in the string message to make character return but I don't want to add this individual custom character for each command return in every static message string I send, Can any who have done this might help me? Basically, something like this,, Write and add function to the program write a command, Reads the respond from a serial device.. Function handles multiple messages, Write: "com open" Read: Welcome to my world" expected Write: "admin" Read: Password?, expected Write: "admin" Read: you are successfully login terminal, expected. And I need to add a separate function handler handles a character return add to the each command above. If anyone can help this I can do the reset? Thank you in advance, John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0035.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SerialIO.java Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0035.pl From Steffen.DETTMER at ingenico.com Wed Aug 13 02:16:38 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 13 Aug 2008 10:16:38 +0200 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: References: Message-ID: <20080813081638.GA25412@elberon.bln.de.ingenico.com> * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > I can do like "login\n" in the string message to make character > return but I don't want to add this individual custom character > for each command return in every static message string I send, and why not?! > Can any who have done this might help me? what's about with writing a small wrapper function adding the carriage return? However, this would be slow, because either you call write two times (very bad) or the string needs to be copied, \n appended and written (since you are using Java Performance probably isn't so critical). Personally I would write `"login\n"' and `username + "\n"' etc., because since it is part of the command it should be part of the command definition string. > Basically, something like this,, Write and add function to the program write > a command, Reads the respond from a serial device.. correctly reading a `line' is more difficult. If you cannot make assumptions about timeouts and/or you need to have low delay, you need to read byte wise. If you need to save CPU resources you might need to add some buffering layer that you can read byte-wise but that is reading blockwise with some small timeout (lets say for serial lines something around byte transmission time times three or so). > /* > * To change this template, choose Tools | Templates > * and open the template in the editor. > */ :) > package joliba; > > /** > * > * @author root > */ :) > // derived from SUN's examples in the javax.comm package > import java.io.*; > import java.util.*; > //import javax.comm.*; // for SUN's serial/parallel port libraries > import gnu.io.*; // for rxtxSerial library > > public class SerialIO implements Runnable, SerialPortEventListener { > static CommPortIdentifier portId; > static CommPortIdentifier saveportId; > static Enumeration portList; > InputStream inputStream; > SerialPort serialPort; > Thread readThread; You need a thread for your synchronous RPC-style protocol? > static String messageString = "Hello, world!"; > static OutputStream outputStream; > static boolean outputBufferEmptyFlag = false; > > public static void main(String[] args) { > boolean portFound = false; > String defaultPort; > > // determine the name of the serial port on several operating systems > String osname = System.getProperty("os.name","").toLowerCase(); > if ( osname.startsWith("windows") ) { > // windows > defaultPort = "COM1"; > } else if (osname.startsWith("linux")) { > // linux > defaultPort = "/dev/ttyS0"; > } else if ( osname.startsWith("mac") ) { > // mac > defaultPort = "????"; > } else { > System.out.println("Sorry, your operating system is not supported"); > return; > } Is such a construction recommended? Isn't there some abstraction (like COM1 working on any platform)? [...] > try { > // activate the OUTPUT_BUFFER_EMPTY notifier > serialPort.notifyOnOutputEmpty(true); > } catch (Exception e) { > System.out.println("Error setting event notification"); > System.out.println(e.toString()); > System.exit(-1); > } I doubt that -1 is defined, probably some 127 or so would be the result, maybe better simply `throw e'? > public void writetoport() { > System.out.println("Writing \""+messageString+"\" to "+serialPort.getName()); > try { > // write string to serial port > outputStream.write(messageString.getBytes()); > } catch (IOException e) {} > } maybe something like /** * Writes the given output string and an additional carriage * return to the current outputStream. */ public void writeStringToPort( /** The output string (without CR). */ String output ) throws IOException { String outputLine = output + "\n"; outputStream.write(outputLine.getBytes()); } ? > > public SerialIO() { > // initalize serial port > try { > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > } catch (PortInUseException e) {} if the port is in use, you continue? Wonder that this works in Java, I would assume serialPort beeing uninitialized which AFAIK is an error in Java. > try { > inputStream = serialPort.getInputStream(); > } catch (IOException e) {} > > try { > serialPort.addEventListener(this); > } catch (TooManyListenersException e) {} > > // activate the DATA_AVAILABLE notifier > serialPort.notifyOnDataAvailable(true); > > try { > // set port parameters > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > } catch (UnsupportedCommOperationException e) {} > > // start the read thread > readThread = new Thread(this); > readThread.start(); > > } I think in all those exception cases you can abort, because it is unlikely that ignoring those errors allow a successful continuation, so in this case maybe it would be better to add a throw clause to the method. > public void run() { > // first thing in the thread, we initialize the write operation > initwritetoport(); > try { > while (true) { > // write string to port, the serialEvent will read it > writetoport(); > Thread.sleep(1000); > } > } catch (InterruptedException e) {} > } Does this make sense? Your `SimpleReadApp' writes one and the same string each second? > public void serialEvent(SerialPortEvent event) { > switch (event.getEventType()) { > case SerialPortEvent.BI: > case SerialPortEvent.OE: > case SerialPortEvent.FE: > case SerialPortEvent.PE: > case SerialPortEvent.CD: > case SerialPortEvent.CTS: > case SerialPortEvent.DSR: > case SerialPortEvent.RI: > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > break; > case SerialPortEvent.DATA_AVAILABLE: > // we get here if data has been received > byte[] readBuffer = new byte[20]; > try { > // read data > while (inputStream.available() > 0) { > int numBytes = inputStream.read(readBuffer); > } > // print data > String result = new String(readBuffer); > System.out.println("Read: "+result); > } catch (IOException e) {} I doubt that this is correct. I would assume you will get a 20 bytes result always, if more bytes would be available they would be printed in a second line but if less bytes are read I'd assume that the buffer/result contains zero bytes from implicite readBuffer contents initialisation (zero is no string terminator in Java AFAIK). > break; > } > } > } oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From florianmanschwetus at gmx.de Wed Aug 13 06:09:31 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 13 Aug 2008 14:09:31 +0200 Subject: [Rxtx] someone has seen such errors? Message-ID: <48A2CEFB.90007@gmx.de> I mean my communication mostly works, but it is far from perfect could this be the reason? Florian Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/949b9947/attachment-0035.bin From superdadusa at gmail.com Wed Aug 13 08:40:32 2008 From: superdadusa at gmail.com (John Choi) Date: Wed, 13 Aug 2008 08:40:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: <20080813081638.GA25412@elberon.bln.de.ingenico.com> References: <20080813081638.GA25412@elberon.bln.de.ingenico.com> Message-ID: Thank you so much Steffen and I will try that suggestion. John On 8/13/08, Steffen DETTMER wrote: > > * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > > I can do like "login\n" in the string message to make character > > return but I don't want to add this individual custom character > > for each command return in every static message string I send, > > and why not?! > > > Can any who have done this might help me? > > what's about with writing a small wrapper function adding the > carriage return? > However, this would be slow, because either you call write two > times (very bad) or the string needs to be copied, \n appended > and written (since you are using Java Performance probably isn't > so critical). > > Personally I would write `"login\n"' and `username + "\n"' etc., > because since it is part of the command it should be part of the > command definition string. > > > Basically, something like this,, Write and add function to the program > write > > a command, Reads the respond from a serial device.. > > correctly reading a `line' is more difficult. If you cannot make > assumptions about timeouts and/or you need to have low delay, you > need to read byte wise. If you need to save CPU resources you > might need to add some buffering layer that you can read > byte-wise but that is reading blockwise with some small timeout > (lets say for serial lines something around byte transmission > time times three or so). > > > /* > > * To change this template, choose Tools | Templates > > * and open the template in the editor. > > */ > > :) > > > package joliba; > > > > /** > > * > > * @author root > > */ > > :) > > > // derived from SUN's examples in the javax.comm package > > import java.io.*; > > import java.util.*; > > //import javax.comm.*; // for SUN's serial/parallel port libraries > > import gnu.io.*; // for rxtxSerial library > > > > public class SerialIO implements Runnable, SerialPortEventListener { > > static CommPortIdentifier portId; > > static CommPortIdentifier saveportId; > > static Enumeration portList; > > InputStream inputStream; > > SerialPort serialPort; > > Thread readThread; > > You need a thread for your synchronous RPC-style protocol? > > > static String messageString = "Hello, world!"; > > static OutputStream outputStream; > > static boolean outputBufferEmptyFlag = false; > > > > public static void main(String[] args) { > > boolean portFound = false; > > String defaultPort; > > > > // determine the name of the serial port on several operating > systems > > String osname = System.getProperty("os.name","").toLowerCase(); > > if ( osname.startsWith("windows") ) { > > // windows > > defaultPort = "COM1"; > > } else if (osname.startsWith("linux")) { > > // linux > > defaultPort = "/dev/ttyS0"; > > } else if ( osname.startsWith("mac") ) { > > // mac > > defaultPort = "????"; > > } else { > > System.out.println("Sorry, your operating system is not > supported"); > > return; > > } > > Is such a construction recommended? Isn't there some abstraction > (like COM1 working on any platform)? > > [...] > > try { > > // activate the OUTPUT_BUFFER_EMPTY notifier > > serialPort.notifyOnOutputEmpty(true); > > } catch (Exception e) { > > System.out.println("Error setting event notification"); > > System.out.println(e.toString()); > > System.exit(-1); > > } > > I doubt that -1 is defined, probably some 127 or so would be the > result, maybe better simply `throw e'? > > > public void writetoport() { > > System.out.println("Writing \""+messageString+"\" to > "+serialPort.getName()); > > try { > > // write string to serial port > > outputStream.write(messageString.getBytes()); > > } catch (IOException e) {} > > } > > maybe something like > > /** > * Writes the given output string and an additional carriage > * return to the current outputStream. > */ > public void > writeStringToPort( > /** The output string (without CR). */ > String output > ) throws IOException > { > String outputLine = output + "\n"; > outputStream.write(outputLine.getBytes()); > } > > ? > > > > > public SerialIO() { > > // initalize serial port > > try { > > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > > } catch (PortInUseException e) {} > > if the port is in use, you continue? Wonder that this works in > Java, I would assume serialPort beeing uninitialized which AFAIK > is an error in Java. > > > try { > > inputStream = serialPort.getInputStream(); > > } catch (IOException e) {} > > > > try { > > serialPort.addEventListener(this); > > } catch (TooManyListenersException e) {} > > > > // activate the DATA_AVAILABLE notifier > > serialPort.notifyOnDataAvailable(true); > > > > try { > > // set port parameters > > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > } catch (UnsupportedCommOperationException e) {} > > > > // start the read thread > > readThread = new Thread(this); > > readThread.start(); > > > > } > > I think in all those exception cases you can abort, because it is > unlikely that ignoring those errors allow a successful > continuation, so in this case maybe it would be better to add a > throw clause to the method. > > > public void run() { > > // first thing in the thread, we initialize the write operation > > initwritetoport(); > > try { > > while (true) { > > // write string to port, the serialEvent will read it > > writetoport(); > > Thread.sleep(1000); > > } > > } catch (InterruptedException e) {} > > } > > Does this make sense? Your `SimpleReadApp' writes one and the > same string each second? > > > public void serialEvent(SerialPortEvent event) { > > switch (event.getEventType()) { > > case SerialPortEvent.BI: > > case SerialPortEvent.OE: > > case SerialPortEvent.FE: > > case SerialPortEvent.PE: > > case SerialPortEvent.CD: > > case SerialPortEvent.CTS: > > case SerialPortEvent.DSR: > > case SerialPortEvent.RI: > > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > > break; > > case SerialPortEvent.DATA_AVAILABLE: > > // we get here if data has been received > > byte[] readBuffer = new byte[20]; > > try { > > // read data > > while (inputStream.available() > 0) { > > int numBytes = inputStream.read(readBuffer); > > } > > // print data > > String result = new String(readBuffer); > > System.out.println("Read: "+result); > > } catch (IOException e) {} > > I doubt that this is correct. I would assume you will get a 20 > bytes result always, if more bytes would be available they would > be printed in a second line but if less bytes are read I'd assume > that the buffer/result contains zero bytes from implicite > readBuffer contents initialisation (zero is no string terminator > in Java AFAIK). > > > break; > > } > > } > > } > > oki, > > Steffen > > About Ingenico Throughout the world businesses rely on Ingenico for secure > and expedient electronic transaction acceptance. Ingenico products leverage > proven technology, established standards and unparalleled ergonomics to > provide optimal reliability, versatility and usability. This comprehensive > range of products is complemented by a global array of services and > partnerships, enabling businesses in a number of vertical sectors to accept > transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged > information. If you are not the addressee or authorized to receive this for > the addressee, you must not use, copy, disclose or take any action based on > this message or any information herein. If you have received this message in > error, please advise the sender immediately by reply e-mail and delete this > message. Thank you for your cooperation. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/73c4135c/attachment-0034.html From ajmas at sympatico.ca Sat Aug 16 07:15:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 09:15:41 -0400 Subject: [Rxtx] someone has seen such errors? In-Reply-To: <48A2CEFB.90007@gmx.de> References: <48A2CEFB.90007@gmx.de> Message-ID: <43B5E8DA-1D93-4D90-809B-AAF35FF724C5@sympatico.ca> On 13-Aug-08, at 08:09 , Florian Manschwetus wrote: > I mean my communication mostly works, but it is far from perfect > could this be the reason? > > Florian > > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control Judging by the error messages this looks related to the driver you are using. Do a search for the following string with you favourite search engine, it should turn up a few hits: ftdi_set_termios FAILED to set databits/stopbits/parity Andre From ajmas at sympatico.ca Sat Aug 16 19:12:04 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 21:12:04 -0400 Subject: [Rxtx] Using SerialPortEvent? Message-ID: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Hi, Could someone tell me how I should be using the SerialPortEvent? Am I meant to be waiting for data and then simply reading from the inputstream? If this is the case why no just block on an inputstream read? Andr? From tjarvi at qbang.org Sat Aug 16 19:41:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 16 Aug 2008 19:41:13 -0600 (MDT) Subject: [Rxtx] Using SerialPortEvent? In-Reply-To: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> References: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Message-ID: On Sat, 16 Aug 2008, Andre-John Mas wrote: > Hi, > > Could someone tell me how I should be using the SerialPortEvent? Am I > meant to be waiting for data and then simply reading from the > inputstream? If this is the case why no just block on an inputstream > read? > Polling for data is fine also. It really depends upon what you are trying to do. For instance, if you require x bytes before reading, you can start polling after data is available. If you read on the same thread as your GUI and are waiting for data in a read, the results may be less than desirable. Java programming is 'usually' event driven rather than polling based. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sat Aug 16 20:10:39 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 22:10:39 -0400 Subject: [Rxtx] Using SerialPortEvent? In-Reply-To: References: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Message-ID: <3E495D4C-BB28-4845-A6AB-984C9A826BDF@sympatico.ca> On 16-Aug-08, at 21:41 , Trent Jarvi wrote: > On Sat, 16 Aug 2008, Andre-John Mas wrote: > >> Hi, >> >> Could someone tell me how I should be using the SerialPortEvent? Am I >> meant to be waiting for data and then simply reading from the >> inputstream? If this is the case why no just block on an inputstream >> read? >> > > Polling for data is fine also. It really depends upon what you are > trying to do. For instance, if you require x bytes before reading, > you can start polling after data is available. If you read on the > same thread as your GUI and are waiting for data in a read, the > results may be less than desirable. > > Java programming is 'usually' event driven rather than polling based. Sounds good. I thought I would use this opportunity to provide a event based version of the TwoWaySerialComm example. Could you just validate it before I add it to the Wiki: package ajmas74.experimental; import gnu.io.CommPort; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; import gnu.io.SerialPortEvent; import gnu.io.SerialPortEventListener; import java.io.IOException; import java.io.InputStream; import java.io.OutputStream; /** * This version of the TwoWaySerialComm example makes use of the * SerialPortEventListener to avoid polling. * * @author ajmas * */ public class TwoWaySerialComm { public TwoWaySerialComm() { super(); } void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { CommPort commPort = portIdentifier.open(this.getClass().getName(),2000); if ( commPort instanceof SerialPort ) { SerialPort serialPort = (SerialPort) commPort; serialPort .setSerialPortParams (57600 ,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); (new Thread(new SerialWriter(out))).start(); serialPort.addEventListener(new SerialReader(in)); } else { System.out.println("Error: Only serial ports are handled by this example."); } } } /** * Handles the input coming from the serial port. A new line character * is treated as the end of a block in this example. */ public static class SerialReader implements SerialPortEventListener { private InputStream in; private byte[] buffer = new byte[1024]; public SerialReader ( InputStream in ) { this.in = in; } public void serialEvent(SerialPortEvent arg0) { int data; try { int len = 0; while ( ( data = in.read()) > -1 ) { if ( data != '\n' ) { break; } buffer[len++] = (byte) data; } System.out.print(new String(buffer,0,len)); } catch ( IOException e ) { e.printStackTrace(); System.exit(-1); } } } /** */ public static class SerialWriter implements Runnable { OutputStream out; public SerialWriter ( OutputStream out ) { this.out = out; } public void run () { try { int c = 0; while ( ( c = System.in.read()) > -1 ) { this.out.write(c); } } catch ( IOException e ) { e.printStackTrace(); System.exit(-1); } } } public static void main ( String[] args ) { try { (new TwoWaySerialComm()).connect("COM3"); } catch ( Exception e ) { e.printStackTrace(); } } } From lfarkas at lfarkas.org Tue Aug 19 07:32:59 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Tue, 19 Aug 2008 15:32:59 +0200 Subject: [Rxtx] JNI or CNI Message-ID: <48AACB8B.9060606@lfarkas.org> hi, what is the current recommended way to rxtx on linux JNI or it's better to use CNI? is the CNI version fully functional and the same level as the JNI? i currently try to make a rhel/centos/fedora rpm for rxtx but has many problems with the standard dir structure. yours. -- Levente "Si vis pacem para bellum!" From lfarkas at lfarkas.org Tue Aug 19 08:47:34 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Tue, 19 Aug 2008 16:47:34 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel Message-ID: <48AADD06.7040809@lfarkas.org> hi, newer or not so newer linux kernel do not contain the UTS_RELEASE so the current rxtx is not compile on the latest kernels. even if it's commented out in the cvs configure there are other places. i attcahed a patch which fix it (or at least doesn't cause error at non-debug build). ps. is there any plan to the new 2.1-8 release in the near future? there are many changes (at least the license change in all file and in this case create a diff is very difficult)? the latest release more then 2 years old:-( -- Levente "Si vis pacem para bellum!" -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-2.1-uts.patch Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080819/ab5d38ac/attachment-0028.pl From ajmas at sympatico.ca Tue Aug 19 16:21:53 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 19 Aug 2008 18:21:53 -0400 Subject: [Rxtx] Event based example Message-ID: <24735BFB-B088-4B84-8173-FE98DF63B12F@sympatico.ca> Hi, I have just posted an example of using SerialPortEventListener in the Wiki: http://rxtx.qbang.org/wiki/index.php/Event_Based_Two_Way_Communication If you see any issues please could you let me know, or makes the changes. Andre From Martin.Oberhuber at windriver.com Fri Aug 22 04:02:24 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 22 Aug 2008 12:02:24 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <48AADD06.7040809@lfarkas.org> References: <48AADD06.7040809@lfarkas.org> Message-ID: <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> Farkas, there are indeed efforts to get a new RXTX release out the door. Your experience as a package maintainer would likely be helpful during these efforts, since I'd think it makes sense to keep the patches minimal that you must make to have the source compile in your environment. What are the things that you find problematic, apart from the UTS thing that you have mentioned before? What is the timing that you have in mind for your package? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Farkas Levente > Sent: Tuesday, August 19, 2008 4:48 PM > To: rxtx at qbang.org > Subject: [Rxtx] UTS_RELEASE not defined in newer kernel > > hi, > newer or not so newer linux kernel do not contain the > UTS_RELEASE so the > current rxtx is not compile on the latest kernels. even if it's > commented out in the cvs configure there are other places. > i attcahed a patch which fix it (or at least doesn't cause error at > non-debug build). > > ps. is there any plan to the new 2.1-8 release in the near > future? there > are many changes (at least the license change in all file and in this > case create a diff is very difficult)? the latest release more then 2 > years old:-( > > -- > Levente "Si vis pacem para bellum!" > From lfarkas at lfarkas.org Fri Aug 22 04:36:26 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Fri, 22 Aug 2008 12:36:26 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> References: <48AADD06.7040809@lfarkas.org> <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> Message-ID: <48AE96AA.6090505@lfarkas.org> hi, the packages already build for fedora-9 and centos-5 and here: http://www.lfarkas.org/linux/packages/ what i've to patch, the UTS, the configure script, but it's already fixed in the cvs (in another way) and the loadlibrary. the reasons for last one can be found here: https://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_files_that_use_JNI after we test it i'd like to add these packages to fedora and epel main repository (that's why it's be useful a new release after 2 years:-) imho versions are cheap and why not just release 2.1-8? the real code changes are minimal and if something critical bug found still can release 2.1-9:-) ps. and would be better to use simple number for version like 2.1-7 rather then 2.1-7v2. Oberhuber, Martin wrote: > Farkas, > > there are indeed efforts to get a new RXTX release out the > door. Your experience as a package maintainer would likely > be helpful during these efforts, since I'd think it makes > sense to keep the patches minimal that you must make to > have the source compile in your environment. > > What are the things that you find problematic, apart from > the UTS thing that you have mentioned before? > > What is the timing that you have in mind for your package? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >> On Behalf Of Farkas Levente >> Sent: Tuesday, August 19, 2008 4:48 PM >> To: rxtx at qbang.org >> Subject: [Rxtx] UTS_RELEASE not defined in newer kernel >> >> hi, >> newer or not so newer linux kernel do not contain the >> UTS_RELEASE so the >> current rxtx is not compile on the latest kernels. even if it's >> commented out in the cvs configure there are other places. >> i attcahed a patch which fix it (or at least doesn't cause error at >> non-debug build). >> >> ps. is there any plan to the new 2.1-8 release in the near >> future? there >> are many changes (at least the license change in all file and in this >> case create a diff is very difficult)? the latest release more then 2 >> years old:-( >> >> -- >> Levente "Si vis pacem para bellum!" >> -- Levente "Si vis pacem para bellum!" From tjarvi at qbang.org Fri Aug 22 18:50:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Aug 2008 18:50:32 -0600 (MDT) Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <48AE96AA.6090505@lfarkas.org> References: <48AADD06.7040809@lfarkas.org> <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> <48AE96AA.6090505@lfarkas.org> Message-ID: Hi Farkas, The v2 was simply the second build - no code changes. We are comming out with a new release shortly. I would encourage working with distros as you are. The building of rxtx turns out to be a bottle neck in quick releases. We do want stable releases that work for a year or more but I would have no problems with quicker cycles on developing work. I would have no problem working with someone that did builds that receive less testing more often but they do have to come out for multiple platforms from this end. Thanks for the links. On Fri, 22 Aug 2008, Farkas Levente wrote: > hi, > the packages already build for fedora-9 and centos-5 and here: > http://www.lfarkas.org/linux/packages/ > what i've to patch, the UTS, the configure script, but it's already > fixed in the cvs (in another way) and the loadlibrary. the reasons for > last one can be found here: > https://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_files_that_use_JNI > after we test it i'd like to add these packages to fedora and epel main > repository (that's why it's be useful a new release after 2 years:-) > imho versions are cheap and why not just release 2.1-8? the real code > changes are minimal and if something critical bug found still can > release 2.1-9:-) > > ps. and would be better to use simple number for version like 2.1-7 > rather then 2.1-7v2. > > Oberhuber, Martin wrote: >> Farkas, >> >> there are indeed efforts to get a new RXTX release out the >> door. Your experience as a package maintainer would likely >> be helpful during these efforts, since I'd think it makes >> sense to keep the patches minimal that you must make to >> have the source compile in your environment. >> >> What are the things that you find problematic, apart from >> the UTS thing that you have mentioned before? >> >> What is the timing that you have in mind for your package? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >>> On Behalf Of Farkas Levente >>> Sent: Tuesday, August 19, 2008 4:48 PM >>> To: rxtx at qbang.org >>> Subject: [Rxtx] UTS_RELEASE not defined in newer kernel >>> >>> hi, >>> newer or not so newer linux kernel do not contain the >>> UTS_RELEASE so the >>> current rxtx is not compile on the latest kernels. even if it's >>> commented out in the cvs configure there are other places. >>> i attcahed a patch which fix it (or at least doesn't cause error at >>> non-debug build). >>> >>> ps. is there any plan to the new 2.1-8 release in the near >>> future? there >>> are many changes (at least the license change in all file and in this >>> case create a diff is very difficult)? the latest release more then 2 >>> years old:-( >>> >>> -- >>> Levente "Si vis pacem para bellum!" >>> > > > From andy at triera.net Sat Aug 23 15:17:44 2008 From: andy at triera.net (Andy Rozman) Date: Sat, 23 Aug 2008 21:17:44 +0000 Subject: [Rxtx] port not identified on FreeBSD In-Reply-To: References: Message-ID: <48B07E78.2030306@triera.net> Hi ! I have one small problem... I have started using FreeBSD in last few days and I have come accross a problem with rxtx on FreeBSD. I am using usb-to-serial converter, which is identified under FreeBSD without problem as ucom0, and creates link under /dev called ttyU0, which is correct way to be done under FreeBSD (if device would be unidentified it would be called ugen0 - as usb generic). Problem is that I say to rxtx to get my all serial ports this one is not among them. Which names are permissable under linux-like implementations? Which will be accepted as serial ports? Andy From tjarvi at qbang.org Sat Aug 23 13:57:45 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 23 Aug 2008 13:57:45 -0600 (MDT) Subject: [Rxtx] port not identified on FreeBSD In-Reply-To: <48B07E78.2030306@triera.net> References: <48B07E78.2030306@triera.net> Message-ID: On Sat, 23 Aug 2008, Andy Rozman wrote: > Hi ! > > I have one small problem... I have started using FreeBSD in last few > days and I have come accross a problem with rxtx on FreeBSD. > > I am using usb-to-serial converter, which is identified under FreeBSD > without problem as ucom0, and creates link under /dev called > ttyU0, which is correct way to be done under FreeBSD (if device would be > unidentified it would be called ugen0 - as usb generic). Problem is that > I say to rxtx to get my all serial ports this one is not among them. > Which names are permissable under linux-like implementations? Which will > be accepted as serial ports? > > Andy > Thanks Andy! We will add ttyU* to FreeBSD. For now you can use properties to enable the port. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting#How_does_rxtx_detect_ports.3F__Can_I_override_it.3F The fix: diff -u -r1.16.2.59 RXTXCommDriver.java --- RXTXCommDriver.java 18 Nov 2007 22:32:41 -0000 1.16.2.59 +++ RXTXCommDriver.java 23 Aug 2008 19:55:25 -0000 @@ -644,6 +644,7 @@ { String[] Temp = { "ttyd", //general purpose serial ports + "ttyU", //general purpose USB serial ports "cuaa", //dialout serial ports "ttyA", //Specialix SI/XIO dialin ports "cuaA", //Specialix SI/XIO dialout ports -- Trent Jarvi tjarvi at qbang.org From rick_knight at rlknight.com Mon Aug 4 13:25:10 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Mon, 04 Aug 2008 12:25:10 -0700 Subject: [Rxtx] Sun's Comm API? Message-ID: <48975796.4010600@rlknight.com> I have an application that requires the javax compatible version of RXTX and Sun's comm api. I've been able to download and extract the version of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api anywhere. Can someone tell me where I can find it? Or maybe send me a copy? Also, when I try to build RXTX, configure and make complete successfully but make install failes with this error libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 I've never come accross this error before. How can I get past it? Thanks, Rick From bboyes at systronix.com Mon Aug 4 19:10:01 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:10:01 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48975796.4010600@rlknight.com> References: <48975796.4010600@rlknight.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/cb9c6167/attachment-0044.html From bboyes at systronix.com Mon Aug 4 19:12:37 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:12:37 -0600 Subject: [Rxtx] Towards an RXTX release - CSR BT/USB chipset In-Reply-To: <488FB7E7.8000802@gmail.com> References: <460801A4097E3D4CA04CC64EE648584806C56CF0@ism-mail03.corp.ad.wrs.com> <13557-75390@sneakemail.com> <20980-23424@sneakemail.com> <488FB7E7.8000802@gmail.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/52236088/attachment-0044.html From tjarvi at qbang.org Mon Aug 4 19:42:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 19:42:21 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: On Mon, 4 Aug 2008, Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: > I have an application that requires the javax compatible > version of RXTX > and Sun's comm api. I've been able to download and extract > the version > of RXTX that I need (2.0-7pre2) but I can't find Sun's camm > api > anywhere. Can someone tell me where I can find it? Or maybe > send me a > > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm port > support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have just > a ZIP with only the .class JAR file - no source or docs), has a readme > with these comments: > > This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release.? The 2.0.3 release itself is > no longer distributed.? comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project.? The RxTx project (http://www.rxtx.org ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org) was opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support.? Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins.? Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > ? > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > I hope that is helpful! > It would be nice to work with Sun to resolve those longstanding issues. But it may not be practical unless the process goes as fast and painless as the grandfathering of commapi did. Another option may be the old kaffe extensions that moved to gnu classpathx. These don't have the native libraries but should provide the 2.0 interface and the javax.comm.properties mechansim for SPI. http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Mon Aug 4 20:23:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Mon, 04 Aug 2008 20:23:57 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4897B9BD.5070809@ergotech.com> Has there been any work/would it be possible, to layer a javacomm look-alike on top of the GNU code? The goal is not to move the javax code forward, but to emulate the "legacy" javax packages for people who still need this. Jim Trent Jarvi wrote: > On Mon, 4 Aug 2008, Bruce Boyes wrote: > >> At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible >> version of RXTX >> and Sun's comm api. I've been able to download and extract >> the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm >> api >> anywhere. Can someone tell me where I can find it? Or maybe >> send me a >> >> >> javaxcomm has had a sort of on-again off-again history. The windoze >> version has been languishing for years (literally) but there are newer >> versions for other OS's. >> >> We try to keep links on one of our help pages current: >> http://www.practicalembeddedjava.com/tools/javatools_list.html >> which gets you to here: >> http://java.sun.com/products/javacomm/ >> where it says in fact they no longer even support Windows and Mac: >> "Implementations of the API are currently available for Solaris SPARC, >> Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so >> someone could support it. But I guess that's part of the reason RXTX >> exists! >> >> So one of Sun's own products, SunSPOT, has to use RXTX to get comm port >> support. >> >> The version we use is 2.0 from 11/15/1998. I have posted it on our >> website, which is within the terms of the license agreement contained >> therein (as I understand it). >> >> The last version of javaxcomm for Windows, 2.0.3, (for which I have just >> a ZIP with only the .class JAR file - no source or docs), has a readme >> with these comments: >> >> This distribution contains the comm.jar file original part >> of the COMMAPI 2.0.3 release. The 2.0.3 release itself is >> no longer distributed. comm.jar, which contains the comm >> API java class files (eg. Sun's binary implementation of the >> interface classes), is being made available, unsupported, >> with no obligation to fix bugs, at the request of the RXTX >> project. The RxTx project (http://www.rxtx.org ), uses the >> comm.jar class files, but provides their own native library >> components to provide support for other platforms. >> >> The 2.0.3 comm.jar is being provided in this way because >> as of COMMAPI 3.x, the java binary implementation forked and >> became incompatible with the RxTx project's native code. >> Due to the lack of a clear business case, and to resource >> constraints, no additional resources are being >> provided to provide an alternative engineering solution >> at the time of writing. >> >> RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: >> >> Ultimately the COMMAPI would be better served if a Java >> Community Process JSR (http://www.jcp.org) was opened and >> the COMMAPI was rearchitected to provide a more pluggable >> framework to improve cross-platform support. Such an >> architecture would embody a better defined and better >> documented SPI interface, including a way for comm. ports >> to be revealed to the client application through the API >> via platform-aware plugins. Similarly, native code used >> to access comm port in general could be handled more >> flexibly using a plugin model, whereby on any platform, >> multiple native modules could be in use simultaneously. >> >> Since there are now various ways serial ports can be implemented >> and accessed, modular comm. port JNI native libraries would be >> of benefit insofar as removing the burden of over-generalization >> from any single native component, or inversely, by relieving the >> implicit constraint that comm. drivers be accessed only via a >> monolithic mechanism, such as the UNIX vnode interface. >> >> paul.klissner at sun.com >> 6/10/06 >> >> I hope that is helpful! >> > > It would be nice to work with Sun to resolve those longstanding issues. > But it may not be practical unless the process goes as fast and painless > as the grandfathering of commapi did. > > Another option may be the old kaffe extensions that moved to gnu > classpathx. These don't have the native libraries but should provide > the 2.0 interface and the javax.comm.properties mechansim for SPI. > > http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Mon Aug 4 21:09:15 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 21:09:15 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? Message-ID: Hi Jim, I will not step into the javax.comm namespace without Sun's explicite permission. I fully understand the pain point you are trying to address. In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm Linux) - which remains an integral part of rxtx. At the time it was a win for Sun and rxtx. The Sun commapi license is/was fairly clear that rxtx should not step into that namespace. It made sense as Sun was active in that space and rxtx may go into another namespace - it was an experiment in working with Sun. This may sound silly looking at something that happened almost 10 years ago. In a community of respect which Sun helped create, there is no question about what to do. I hope eventually Sun will step up and do a right thing too. I agree that this is hurting the API more than helping it. There are also questions about how to replace the API in the long term which includes HID support which isn't going well so far. Others that can't even look at Sun's javax.comm today and can look at Kaffe's contribution to classpathx can easily work around such restrictions. On Mon, 4 Aug 2008, Jim Redman wrote: > Has there been any work/would it be possible, to layer a javacomm > look-alike on top of the GNU code? > > The goal is not to move the javax code forward, but to emulate the > "legacy" javax packages for people who still need this. > > Jim > > Trent Jarvi wrote: >> >> It would be nice to work with Sun to resolve those longstanding issues. >> But it may not be practical unless the process goes as fast and painless >> as the grandfathering of commapi did. >> >> Another option may be the old kaffe extensions that moved to gnu >> classpathx. These don't have the native libraries but should provide >> the 2.0 interface and the javax.comm.properties mechansim for SPI. >> >> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From florianmanschwetus at gmx.de Tue Aug 5 05:04:46 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 13:04:46 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: References: <48971C1F.9020806@gmx.de> Message-ID: <489833CE.1040801@gmx.de> Just look at sendCommand in this method I have to place a Thread.sleep(20) after each byte send to get working. Even the event based receive doesn't work fine but this could be may stupidness. The specifikation document (it is on the last pages of the manual) for the beamer could be found on: http://www.optoma.co.uk/support.aspx Florian Manschwetus Trent Jarvi schrieb: > > Hi Florian > > Sorry for the top post in advance. I worry you may not see my answer > under all your code :) > > I have not received this email before. This is 500k of code which I > don't have time to read. I can spend about 5 min on each hobby email > and still get to work in the morning. I have a couple suggestions for > how to get an answer. > > First, cut out your comments and extra code so you can demonstrate the > question (I might even glance and see what is wrong then). Don't go for > a working final product. Isolate the problem using a simple program and > then ask with that as an example. If I did what you just did, I'd have > to post 3/4 of a million lines of code :) > > Second, join the rxtx mail-list and ask there. This will give you 100x > more eyes. I'll also read and try to follow. > > -- > taj > > > > On Mon, 4 Aug 2008, Florian Manschwetus wrote: > >> It could be that my university account is blocked by filters so >> resending from here. >> >> >> Topic is to control Optoma HD80 beamer using rs232 serial chat. >> This code is able to detect power state and switch the beamer on / off. >> connected is the beamer using a digitus usb 2.0 serial adapter with an >> FT232 USB-Serial adapter the systems architecture is amd64. >> >> Please take a look in the sendCommand routine i have to place theire >> those Thread.sleep to get it working. >> Now the question is this correct or is there a better way to get this >> working correctly? >> >> In the javadoc coming with the install i found this: >> setBaudBase >> >> public boolean setBaudBase(int BaudBase) >> throws UnsupportedCommOperationException, >> java.io.IOException >> >> Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 >> before using. >> >> could this explain the error? >> I attached my java source and the protocol description for the beamer >> (available on vendor website). >> >> thx, >> Florian Manschwetus >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: TestRS232.java Type: text/x-java Size: 9143 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0088.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0089.bin From michael.erskine at ketech.com Tue Aug 5 05:53:49 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Tue, 5 Aug 2008 12:53:49 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489833CE.1040801@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> > Just look at sendCommand in this method I have to place a > Thread.sleep(20) after each byte send to get working. Even the event > based receive doesn't work fine but this could be may stupidness. Hi Florian, Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. Regards, Michael Erskine. From florianmanschwetus at gmx.de Tue Aug 5 07:28:15 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:28:15 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> Message-ID: <4898556F.8000208@gmx.de> Michael Erskine schrieb: >> Just look at sendCommand in this method I have to place a >> Thread.sleep(20) after each byte send to get working. Even the event >> based receive doesn't work fine but this could be may stupidness. > > Hi Florian, > > Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. > > Regards, > Michael Erskine. > Ok, sounds fine for the receiving problem. But why i have to wait after each byte when sending a command squence? (the for loop in send command) Florian > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/284f350c/attachment-0043.bin From florianmanschwetus at gmx.de Tue Aug 5 07:44:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:44:14 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <4898592E.2020908@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >>> Just look at sendCommand in this method I have to place a >>> Thread.sleep(20) after each byte send to get working. Even the event >>> based receive doesn't work fine but this could be may stupidness. >> >> Hi Florian, >> >> Yes, naturally you'll have to wait for a response from the other end. >> Why not wait for notification from the event thread perhaps using a >> BlockingDeque rather than your LinkedList. Generally I >> try to decouple all input and output streams: in your case your >> application is operating synchronously like the "expect" program >> (http://expect.nist.gov/) so waits (or timeouts) will need to be >> factored in. >> >> Regards, >> Michael Erskine. >> > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) > > Florian Furthermore there is this basic baud with this confusing javadoc entry: public boolean setBaudBase(int BaudBase) throws UnsupportedCommOperationException, java.io.IOException Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 before using. maybe this could explain something Florian >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/006c7425/attachment-0043.bin From jredman at ergotech.com Tue Aug 5 09:13:36 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 05 Aug 2008 09:13:36 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: Message-ID: <48986E20.3060104@ergotech.com> Trent, So two issues: 1) Technically I'm still not sure how easy/practical a layer would be. The problems are always classes like listeners, and wrapping returns of gnu.io classes. I really see it as a "delegate" type of concept. Any thoughts or ideas of the practicality of this approach? The idea is not to modify RXTX. 2) Javax. The javax namespace does seem to be in widespread use outside of Sun (the same is true for the java namespace). The classpath extensions, or some other location, should be interested in a JavaComm implementation even if it does have dependencies on RXTX. Would you have any philosophical objection to an approach like that? Of course, I suspect it might be better if someone with that authority at Sun would admit that the javax namespace is already in the wild and that there is no problem with it being used within RXTX. Jim Trent Jarvi wrote: > Hi Jim, > > I will not step into the javax.comm namespace without Sun's explicite > permission. I fully understand the pain point you are trying to address. > > In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm > Linux) - which remains an integral part of rxtx. At the time it was a win for > Sun and rxtx. > > The Sun commapi license is/was fairly clear that rxtx should not step into that > namespace. It made sense as Sun was active in that space and rxtx may go into > another namespace - it was an experiment in working with Sun. > > This may sound silly looking at something that happened almost 10 years ago. > In a community of respect which Sun helped create, there is no question about > what to do. I hope eventually Sun will step up and do a right thing too. > > I agree that this is hurting the API more than helping it. There are also > questions about how to replace the API in the long term which includes HID > support which isn't going well so far. > > Others that can't even look at Sun's javax.comm today and can look at Kaffe's > contribution to classpathx can easily work around such restrictions. > > On Mon, 4 Aug 2008, Jim Redman wrote: > >> Has there been any work/would it be possible, to layer a javacomm >> look-alike on top of the GNU code? >> >> The goal is not to move the javax code forward, but to emulate the >> "legacy" javax packages for people who still need this. >> >> Jim >> >> Trent Jarvi wrote: >>> It would be nice to work with Sun to resolve those longstanding issues. >>> But it may not be practical unless the process goes as fast and painless >>> as the grandfathering of commapi did. >>> >>> Another option may be the old kaffe extensions that moved to gnu >>> classpathx. These don't have the native libraries but should provide >>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>> >>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From sandeep at genevasoftech.com Tue Aug 5 11:18:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Tue, 05 Aug 2008 22:48:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <48988B6C.5080409@genevasoftech.com> Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. *-- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/ad20f1cb/attachment-0043.html From Martin.Oberhuber at windriver.com Tue Aug 5 13:30:17 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Tue, 5 Aug 2008 21:30:17 +0200 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Sandeep, shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on Sol7 but I've successfully run it on Sol9 and Sol10. Or is your request really about a native 64bit variant? I'm afraid that then you're out of luck since I think that quite a bit of RXTX is not yet ready for 64 bit. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Sandeep Kumar K Sent: Tuesday, August 05, 2008 7:19 PM To: rxtx at qbang.org Subject: [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so for Solaris 9 Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. -- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/81b7f988/attachment-0043.html From tjarvi at qbang.org Tue Aug 5 22:38:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 22:38:34 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 5 Aug 2008, Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built > on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid that > then > you're out of luck since I think that quite a bit of RXTX is not yet > ready > for 64 bit. > While rxtx-2.1-7 probably has problems, The CVS code should be OK for 64 bit Solaris. If it isn't, let me know and I'll find which patch is missing. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Aug 5 23:13:00 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 23:13:00 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48986E20.3060104@ergotech.com> References: <48986E20.3060104@ergotech.com> Message-ID: On Tue, 5 Aug 2008, Jim Redman wrote: > Trent, > > So two issues: > > 1) Technically I'm still not sure how easy/practical a layer would be. The > problems are always classes like listeners, and wrapping returns of gnu.io > classes. I really see it as a "delegate" type of concept. Any thoughts or > ideas of the practicality of this approach? The idea is not to modify RXTX. I have not put too much thought into this. I assume you want what rxtx 2.0 provided to tie into javax.comm implementations. More classes could be added to rxtx 2.1-7 for SPI support. Maintaining rxtx-2.0 could also be handed to someone if they like. > > 2) Javax. The javax namespace does seem to be in widespread use outside of > Sun (the same is true for the java namespace). The classpath extensions, or > some other location, should be interested in a JavaComm implementation even > if it does have dependencies on RXTX. Would you have any philosophical > objection to an approach like that? > No problems. Classpathx would be a possible place to do it. I'd suggest thinking twice about what this involves in practical terms. You would be wanting to revive the 2.0 API while Sun is at 3.0 and grandfathering the JSR. This undermines the main reason (established api) for using the javax.comm namespace and does not leave such a project in a good position. The only win I see here is maintaining support for applications that can't migrate namespaces. Not that that isn't important. At some point it is going to be less work to just edit the bytecode :) Such a javax.comm effort would also be signing up new projects that decided to use the work up for concerns they probably will not understand or expect. That probably isn't a good path to facilitate for new projects at this time. We will put a good faith effort to work well with others but keep in mind the project has limited bandwidth for such efforts. > Of course, I suspect it might be better if someone with that authority at Sun > would admit that the javax namespace is already in the wild and that there is > no problem with it being used within RXTX. > > Jim > > Trent Jarvi wrote: >> Hi Jim, >> >> I will not step into the javax.comm namespace without Sun's explicite >> permission. I fully understand the pain point you are trying to address. >> >> In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java >> Comm Linux) - which remains an integral part of rxtx. At the time it was a >> win for Sun and rxtx. >> >> The Sun commapi license is/was fairly clear that rxtx should not step into >> that namespace. It made sense as Sun was active in that space and rxtx may >> go into another namespace - it was an experiment in working with Sun. >> >> This may sound silly looking at something that happened almost 10 years >> ago. In a community of respect which Sun helped create, there is no >> question about what to do. I hope eventually Sun will step up and do a >> right thing too. >> >> I agree that this is hurting the API more than helping it. There are also >> questions about how to replace the API in the long term which includes HID >> support which isn't going well so far. >> >> Others that can't even look at Sun's javax.comm today and can look at >> Kaffe's contribution to classpathx can easily work around such >> restrictions. >> >> On Mon, 4 Aug 2008, Jim Redman wrote: >> >>> Has there been any work/would it be possible, to layer a javacomm >>> look-alike on top of the GNU code? >>> >>> The goal is not to move the javax code forward, but to emulate the >>> "legacy" javax packages for people who still need this. >>> >>> Jim >>> >>> Trent Jarvi wrote: >>>> It would be nice to work with Sun to resolve those longstanding issues. >>>> But it may not be practical unless the process goes as fast and painless >>>> as the grandfathering of commapi did. >>>> >>>> Another option may be the old kaffe extensions that moved to gnu >>>> classpathx. These don't have the native libraries but should provide >>>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>>> >>>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From sandeep at genevasoftech.com Wed Aug 6 00:03:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Wed, 06 Aug 2008 11:33:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: <48993EB8.30107@genevasoftech.com> Thank you Mr. Martin for your suggestion. The native file which is given in rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am getting the following error . Any suggestions to solve this issue. I am using Solaris SPARC 64 bit machine. ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) thrown while loading gnu.io.RXTXCommDriver Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(Unknown Source) at java.lang.ClassLoader.loadLibrary(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) at com.ReadFromModem.main(ReadFromModem.java:84) * * *Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid > that then > you're out of luck since I think that quite a bit of RXTX is not yet ready > for 64 bit. > > Cheers, > -- > *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > ------------------------------------------------------------------------ > *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On > Behalf Of *Sandeep Kumar K > *Sent:* Tuesday, August 05, 2008 7:19 PM > *To:* rxtx at qbang.org > *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so > for Solaris 9 > > Hi, > > Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 > bit machine. The librxtxSerial.so given in website is for Solaris 8. > > *-- > > Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/1e920343/attachment-0043.html From tjarvi at qbang.org Wed Aug 6 00:21:42 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 00:21:42 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <48993EB8.30107@genevasoftech.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> <48993EB8.30107@genevasoftech.com> Message-ID: Hi Sandeep You may be out of luck unless you can compile the 2.1 src in CVS (requires gnu make and gcc). But you could try the ToyBox(R)(TM) which is a collection of WiLdLy untested cross compiled 2.1-7 binaries covering everything from the ibm z series to embeded arm/ppc. To give an idea how poorly these are tested, I don't even know if z series machines have a serial port. ftp://www.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Solaris They should at least match the binary types. Actually, I think if you use the rxtx jar from CVS with that file, it should 'work' as the fix for 64 bits was in java not the native code. You could just cd rxtx*/src; javac *.java then jar -cf RXTXcomm.jar `find -name \*.class` to create the hybrid which will complain about version information a bit. On Wed, 6 Aug 2008, Sandeep Kumar K wrote: > Thank you Mr. Martin for your suggestion. The native file which is given in > rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am > getting the following error . > Any suggestions to solve this issue. > I am using Solaris SPARC 64 bit machine. > > ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar > java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 > (Possible cause: architecture word > width mismatch) thrown while loading gnu.io.RXTXCommDriver > Exception in thread "main" java.lang.UnsatisfiedLinkError: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF > class: ELFCLASS64 (Possible cause: > architecture word width mismatch) > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(Unknown Source) > at java.lang.ClassLoader.loadLibrary(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > at com.ReadFromModem.main(ReadFromModem.java:84) > > * > * > > *Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > > > Oberhuber, Martin wrote: >> Sandeep, >> shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse >> variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on >> Sol7 but I've successfully run it on Sol9 and Sol10. >> Or is your request really about a native 64bit variant? I'm afraid that >> then >> you're out of luck since I think that quite a bit of RXTX is not yet ready >> for 64 bit. >> Cheers, >> -- >> *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> ------------------------------------------------------------------------ >> *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On >> Behalf Of *Sandeep Kumar K >> *Sent:* Tuesday, August 05, 2008 7:19 PM >> *To:* rxtx at qbang.org >> *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so >> for Solaris 9 >> >> Hi, >> >> Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 >> bit machine. The librxtxSerial.so given in website is for Solaris 8. >> >> *-- >> Thanks & Regards >> >> Sandeep Kumar K >> Sr. Software Engineer >> Geneva Software Technologies >> Whitefield, Bangalore >> Mob : 9880193454* >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> From michael.erskine at ketech.com Wed Aug 6 01:39:28 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 6 Aug 2008 08:39:28 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Florian Manschwetus wrote: > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) Hi Florian, I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. Regards, Michael Erskine. From florianmanschwetus at gmx.de Wed Aug 6 02:53:16 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 06 Aug 2008 10:53:16 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Message-ID: <4899667C.6010706@gmx.de> Michael Erskine schrieb: > Florian Manschwetus wrote: >> Ok, sounds fine for the receiving problem. >> But why i have to wait after each byte when sending a command squence? >> (the for loop in send command) > > Hi Florian, > I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. > > Regards, > Michael Erskine. > correct with a terminal on the other end it works, my idea was that this basic baud has some influence. Could some one explain what it is for? Florian > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/c2b4fa84/attachment-0043.bin From rick_knight at rlknight.com Wed Aug 6 13:01:07 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:01:07 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F4F3.3020707@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > I have an application (Readerware) that uses RXTX with Javax to access the serial port. This used to work fine under previous Linux' and Java, but something has changed, I assume with Java itself , that is causing the application to fail with a link error. The application is not able to find librxtxSerialParallel.so. RXTX supplies librxtxSerial.so and librxtxParallel.so, but not librxtxSerialParallel.so. Where can I get librxtxSerialParallel.so, or do I need it? Is something else causing the lib to not be found? Thanks, Rick Knight From rick_knight at rlknight.com Wed Aug 6 13:17:55 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:17:55 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F8E3.5060400@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Thanks for the reply. The developer of the app I'm trying to use (Readerware) has sent me a copy of the comm.api and I've copied the library (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar into the proper places. When I try to run the application, I get this error... Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: /usr/lib/libSolarisSerialParallel.so: /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not little-endian (Possible cause: endianness mismatch) Caught java.lang.UnsatisfiedLinkError: com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I while loading driver com.sun.comm.SolarisDriver Is there a way around this error? Thanks again, Rick Knight From jlar310 at gmail.com Wed Aug 6 13:37:42 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 14:37:42 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899F8E3.5060400@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > The developer of the app I'm trying to use (Readerware) has sent me a > copy of the comm.api and I've copied the library > (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar > into the proper places. When I try to run the application, I get this > error... > > Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: > /usr/lib/libSolarisSerialParallel.so: > /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not > little-endian (Possible cause: endianness mismatch) > Caught java.lang.UnsatisfiedLinkError: > com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I > > while loading driver com.sun.comm.SolarisDriver > > Is there a way around this error? What host OS are you running? From your original post it looks like 32 bit Linux. The libSolarisSerialParallel.so file is for Sun Solaris and will vary depending on the underlying hardware architecture as well. Sorry for the double post Rick, but I failed to send this to the list the first time... -- Jeff From rick_knight at rlknight.com Wed Aug 6 13:44:29 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:44:29 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: <4899FF1D.9030504@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > > >> The developer of the app I'm trying to use (Readerware) has sent me a >> copy of the comm.api and I've copied the library >> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >> into the proper places. When I try to run the application, I get this >> error... >> >> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >> /usr/lib/libSolarisSerialParallel.so: >> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >> little-endian (Possible cause: endianness mismatch) >> Caught java.lang.UnsatisfiedLinkError: >> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >> >> while loading driver com.sun.comm.SolarisDriver >> >> Is there a way around this error? >> > > What host OS are you running? From your original post it looks like 32 > bit Linux. > > The libSolarisSerialParallel.so file is for Sun Solaris and will vary > depending on the underlying hardware architecture as well. > > I'm running Kubuntu Linux (debian based). It's 32 bit. Rick Knight From jlar310 at gmail.com Wed Aug 6 15:33:23 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 16:33:23 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > I don't think Sun did binary libraries for Linux in the 2.0 version. Can someone with more historical experience than I confirm that? I recently tried to port a Comm API application from Solaris sparc to Linux x86 and likewise could not get my hands on the binary libraries. I eventually just re-wrote the code to use the gnu namespace packages and rxtx 2.1. What I don't understand is why your application vendor does not provide everything you need to run their software. FYI: I have librxtxParallel.so and librxtxSerial.so installed at JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is /usr/java/default which is actually a softlink to /usr/java/jre1.6.0_05. -- Jeff From defiantlew at yahoo.com.au Wed Aug 6 16:29:33 2008 From: defiantlew at yahoo.com.au (Lew L) Date: Thu, 7 Aug 2008 08:29:33 +1000 Subject: [Rxtx] Sun's Comm API Documentation References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> Message-ID: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> As a matter of interest is the Sun Comm API documentation available somewhere? I have tried the Sun site but it seems to have been removed. Unless I have missed the documentation for RXTX? I javadocced the RXTX source but information (to me) is minimal. Somewhere I got the impression that the Sun Comm API docs is, or was, compatible with RXTX, what is the best docs to use in conjuntion with RXTX and where may the be available? Cheers Lew From rick_knight at rlknight.com Wed Aug 6 17:18:33 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:18:33 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A3149.4050306@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff I'm not sure if I posted this here or not, but when I try to build RXTX from source I get this install error... make all-am make[1]: Entering directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' make[1]: Nothing to be done for `all-am'. make[1]: Leaving directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 Can you tell me how to get past this error and get RXTX built and installed? Thanks, Rick From bboyes at systronix.com Wed Aug 6 17:40:12 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Wed, 06 Aug 2008 17:40:12 -0600 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: At 16:29 08/06/2008, Lew L wrote: >As a matter of interest is the Sun Comm API documentation available >somewhere? I have tried the Sun site but it seems to have been removed. It's in the file we have posted, link in prev email (sorry, in a huge hurry right now). Javadocs definitely there. >Unless I have missed the documentation for RXTX? I javadocced the RXTX >source but information (to me) is minimal. >Somewhere I got the impression that the Sun Comm API docs is, or was, >compatible with RXTX, what is the best docs to use in conjuntion with RXTX >and where may the be available? Yeah, this is one of my concerns/beefs. There is little documentation for RXTX and it isn't just the same as javaxcomm. I would be willing to help out writing docs for RXTX! Yes really... esp if we can fix the Bluetooth issues. best regards Bruce >Cheers >Lew > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx ------- WWW.SYSTRONIX.COM ---------- Real embedded Java and much more +1-801-534-1017 Salt Lake City, USA From rick_knight at rlknight.com Wed Aug 6 17:54:08 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:54:08 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A39A0.2090309@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff, I would like for my vendor to switch to rxtx 2.1. It would make things much easier for me. I'm not sure why he's still using the javax compatible code. He's a small operation. Re-writing the code to use gnu namespace sounds like a major overhaul. Was it? Thanks, Rick From tjarvi at qbang.org Wed Aug 6 21:35:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:35:12 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: >> >>> Jeff wrote: >>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>>> >>>> >>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things > much easier for me. I'm not sure why he's still using the javax > compatible code. He's a small operation. Re-writing the code to use gnu > namespace sounds like a major overhaul. Was it? > Hi Jeff, The changes are fairly mechanical. Imports need to change and any explicite use of the namespace needs to change such as catching an exception. The following script was made for maintaining rxtx 2.0 but can apply to other needs. It is in the contrib dir with rxtx source. #!/bin/sh # Don't use! :) # # Sat, 03 May 2003 16:45:08 Modifications from J?rg Weule # Create a ed-cmd for the change of one pattern # case $1 in gnu) X=g/javax_comm/s+javax_comm+gnu_io+g ;; javax) X=g/gnu_io/s+gnu_io+javax_comm+g ;; *) echo;echo;echo From the top rxtx directory run;echo;echo -e \\t./ChangePackage.sh gnu;echo -e \\t\\tor;echo -e \\t./ChangePackage.sh javax;echo;echo; exit 0 ;; esac # # ed will be used to keep the owner and mode of the files unchanged. # We have run the ed-script for the characters '.' '/' as well. # "tr _ $D" do the change. # find . -type f -a -print | grep -v $0 | (while read F ; do ( echo $X; echo $X| tr _ /; echo $X| tr _ .; echo w; echo q ) | ed $F 2>&1 >/dev/null done ) # # Now we do little changes at the Makefiles. Hope that all we need. # find . -name Makefile\* -a -print | (while read F ; do cat < References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: On Thu, 7 Aug 2008, Lew L wrote: > As a matter of interest is the Sun Comm API documentation available > somewhere? I have tried the Sun site but it seems to have been removed. > > Unless I have missed the documentation for RXTX? I javadocced the RXTX > source but information (to me) is minimal. > Somewhere I got the impression that the Sun Comm API docs is, or was, > compatible with RXTX, what is the best docs to use in conjuntion with RXTX > and where may the be available? > Hi Lew, The documentation on Sun's website is accurate. The changes that are problematic in 3.0 are on the backside which rxtx used to plug into. http://java.sun.com/products/javacomm/reference/api/index.html CommPortIdentifier may have some minor differences (judging by the authors notes). -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Aug 6 21:46:08 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:46:08 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > If javax.comm.properties is properly installed and you are using a 2.0 version of Sun's commapi with rxtx 2.0, you should not see the library attempt to load libSolarisSerialParallel.so. Sun CommAPI 3.0 will not work with any version of rxtx as it is hard coded to use the shared library. See the INSTALL file with rxtx-2.0 source for more help with the properties file. -- Trent Jarvi tjarvi at qbang.org From jlar310 at gmail.com Thu Aug 7 06:32:06 2008 From: jlar310 at gmail.com (Jeff) Date: Thu, 7 Aug 2008 07:32:06 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > Jeff wrote: >> >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >> wrote: >> >>> >>> Jeff wrote: >>> >>>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>> wrote: >>>> >>>> >>>> >>>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things much > easier for me. I'm not sure why he's still using the javax compatible code. > He's a small operation. Re-writing the code to use gnu namespace sounds like > a major overhaul. Was it? I found it quite easy. In fact, in order to accommodate the transition, I actually separated all of the code that deals directly with the Comm API or RXTX into a helper class. The helper class was then coded to use reflection to determine which library was available and then instantiate the necessary objects. No direct imports of either library are used. The main application just needs to get it's hands on the IO streams and need not deal directly with the libraries. Other programs may not be so simple... But this doesn't really help you unless your vendor forks over the source code... -- Jeff From rick_knight at rlknight.com Thu Aug 7 09:47:12 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Thu, 07 Aug 2008 08:47:12 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: <489B1900.10108@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >>> wrote: >>> >>> >>>> Jeff wrote: >>>> >>>> >>>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>>> copy of the comm.api and I've copied the library >>>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>>> into the proper places. When I try to run the application, I get this >>>>>> error... >>>>>> >>>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>>> /usr/lib/libSolarisSerialParallel.so: >>>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>>> little-endian (Possible cause: endianness mismatch) >>>>>> Caught java.lang.UnsatisfiedLinkError: >>>>>> >>>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>>> >>>>>> while loading driver com.sun.comm.SolarisDriver >>>>>> >>>>>> Is there a way around this error? >>>>>> >>>>>> >>>>>> >>>>> What host OS are you running? From your original post it looks like 32 >>>>> bit Linux. >>>>> >>>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>>> depending on the underlying hardware architecture as well. >>>>> >>>>> >>>>> >>>>> >>>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>>> >>>> >>>> >>> I don't think Sun did binary libraries for Linux in the 2.0 version. >>> Can someone with more historical experience than I confirm that? >>> >>> I recently tried to port a Comm API application from Solaris sparc to >>> Linux x86 and likewise could not get my hands on the binary libraries. >>> I eventually just re-wrote the code to use the gnu namespace packages >>> and rxtx 2.1. >>> >>> What I don't understand is why your application vendor does not >>> provide everything you need to run their software. >>> >>> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >>> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >>> /usr/java/default which is actually a softlink to >>> /usr/java/jre1.6.0_05. >>> >>> >>> >> Jeff, >> >> I would like for my vendor to switch to rxtx 2.1. It would make things much >> easier for me. I'm not sure why he's still using the javax compatible code. >> He's a small operation. Re-writing the code to use gnu namespace sounds like >> a major overhaul. Was it? >> > > I found it quite easy. In fact, in order to accommodate the > transition, I actually separated all of the code that deals directly > with the Comm API or RXTX into a helper class. The helper class was > then coded to use reflection to determine which library was available > and then instantiate the necessary objects. No direct imports of > either library are used. The main application just needs to get it's > hands on the IO streams and need not deal directly with the libraries. > Other programs may not be so simple... > > But this doesn't really help you unless your vendor forks over the > source code... > > Jeff, This may not help me directly, but I'm going to forward this thread to the vendor. I think he'll be open to making things work. Thanks again, Rick Knight From agusmunioz at gmail.com Thu Aug 7 16:39:51 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Thu, 7 Aug 2008 19:39:51 -0300 Subject: [Rxtx] How to send ack? Message-ID: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Hi, I'm still learning about serial communication and I have some doubts. I've got this question about how to do the following thing in rxtx. I have this hardware that connect to a PC using a serial port. These hardware receives data from a telephone line, proccess it, and then send it forward to the serial port. I've used a program named wincomm that shows what information is send it through the serial port and I have the nex behaviour: The hardware has a buffer where all data is stored, that cannot be sent it through the seria port. The program reads the first data send it by the hardware, and keep reading the same data always. There is a button in the application that says enable Ack, and when I click, then the hardware start to send all the stored information, and all the information is shown. I write a class, using rxtx that reads the serial port, and the same thing happens, it remains reading the same (first) data all the time. And I thing something like the enable Ack I'm missing. How can I do this enable Ack from my java code using rxtx? Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080807/e0a0f9a1/attachment-0041.html From ajmas at sympatico.ca Thu Aug 7 18:26:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 7 Aug 2008 20:26:41 -0400 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: <4BF42297-81E2-4BB8-A89F-1D43588379AE@sympatico.ca> On 6-Aug-08, at 19:40 , Bruce Boyes wrote: >> Unless I have missed the documentation for RXTX? I javadocced the >> RXTX >> source but information (to me) is minimal. >> Somewhere I got the impression that the Sun Comm API docs is, or was, >> compatible with RXTX, what is the best docs to use in conjuntion >> with RXTX >> and where may the be available? > > Yeah, this is one of my concerns/beefs. There is little documentation > for RXTX and it isn't just the same as javaxcomm. > > I would be willing to help out writing docs for RXTX! Yes really... > esp if we can fix the Bluetooth issues. If you want to contribute documentation then the best place to do that is the wiki. If there is anything missing or that could be improved on then please do so. If there are any points that you would like to see improved, for which you don't have the knowledge then ask on the mailing list for a volunteer. Andre From florianmanschwetus at gmx.de Fri Aug 8 03:04:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Fri, 08 Aug 2008 11:04:14 +0200 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Message-ID: <489C0C0E.2020401@gmx.de> Agustin Mu?oz schrieb: > Hi, I'm still learning about serial communication and I have some > doubts. I've got this question about how to do the following thing in rxtx. > I have this hardware that connect to a PC using a serial port. These > hardware receives data from a telephone line, proccess it, and then send > it forward to the serial port. I've used a program named wincomm that > shows what information is send it through the serial port and I have the > nex behaviour: > > The hardware has a buffer where all data is stored, that cannot be sent > it through the seria port. > The program reads the first data send it by the hardware, and keep > reading the same data always. > There is a button in the application that says enable Ack, and when I > click, then the hardware start to send all the stored information, and > all the information is shown. > > I write a class, using rxtx that reads the serial port, and the same > thing happens, it remains reading the same (first) data all the time. > And I thing something like the enable Ack I'm missing. > How can I do this enable Ack from my java code using rxtx? Afaik, a look at man ascii reveals: Okt Dez Hex Char 006 6 06 ACK So, i hope this will do the job: send(6); florian > > Thanks in advance > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/5b4965f8/attachment-0041.bin From agusmunioz at gmail.com Fri Aug 8 16:31:00 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 19:31:00 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <489C0C0E.2020401@gmx.de> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> Message-ID: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Hi Florian, thanks for the answer. By send(6) you mean to get the port OutputStream and write a 6? I try that but it didn't work. Any suggestion? Thanks On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < florianmanschwetus at gmx.de> wrote: > Agustin Mu?oz schrieb: > > Hi, I'm still learning about serial communication and I have some doubts. >> I've got this question about how to do the following thing in rxtx. >> I have this hardware that connect to a PC using a serial port. These >> hardware receives data from a telephone line, proccess it, and then send it >> forward to the serial port. I've used a program named wincomm that shows >> what information is send it through the serial port and I have the nex >> behaviour: >> >> The hardware has a buffer where all data is stored, that cannot be sent >> it through the seria port. >> The program reads the first data send it by the hardware, and keep reading >> the same data always. >> There is a button in the application that says enable Ack, and when I >> click, then the hardware start to send all the stored information, and all >> the information is shown. >> >> I write a class, using rxtx that reads the serial port, and the same thing >> happens, it remains reading the same (first) data all the time. And I thing >> something like the enable Ack I'm missing. >> How can I do this enable Ack from my java code using rxtx? >> > Afaik, a look at man ascii reveals: > Okt Dez Hex Char > 006 6 06 ACK > So, i hope this will do the job: > send(6); > > florian > >> >> Thanks in advance >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/7f3fba42/attachment-0040.html From agusmunioz at gmail.com Fri Aug 8 18:39:27 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 21:39:27 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Message-ID: <988288430808081739x7f9e7889id82591d5a9e2b4f6@mail.gmail.com> Ok, Florian, it works!! my problem was that I've been sending, through the OutputStream, the bytes of 6 as a string: out.write("6".getBytes()); but then I realized that you can write an int on an OuptuStream, so I tried that and It works: out.write(6); Thank you for the guidance!! On Fri, Aug 8, 2008 at 7:31 PM, Agustin Mu?oz wrote: > Hi Florian, thanks for the answer. By send(6) you mean to get the port > OutputStream and write a 6? > > I try that but it didn't work. > > Any suggestion? > > Thanks > > > On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < > florianmanschwetus at gmx.de> wrote: > >> Agustin Mu?oz schrieb: >> >> Hi, I'm still learning about serial communication and I have some doubts. >>> I've got this question about how to do the following thing in rxtx. >>> I have this hardware that connect to a PC using a serial port. These >>> hardware receives data from a telephone line, proccess it, and then send it >>> forward to the serial port. I've used a program named wincomm that shows >>> what information is send it through the serial port and I have the nex >>> behaviour: >>> >>> The hardware has a buffer where all data is stored, that cannot be sent >>> it through the seria port. >>> The program reads the first data send it by the hardware, and keep >>> reading the same data always. >>> There is a button in the application that says enable Ack, and when I >>> click, then the hardware start to send all the stored information, and all >>> the information is shown. >>> >>> I write a class, using rxtx that reads the serial port, and the same >>> thing happens, it remains reading the same (first) data all the time. And I >>> thing something like the enable Ack I'm missing. >>> How can I do this enable Ack from my java code using rxtx? >>> >> Afaik, a look at man ascii reveals: >> Okt Dez Hex Char >> 006 6 06 ACK >> So, i hope this will do the job: >> send(6); >> >> florian >> >>> >>> Thanks in advance >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/b918ab3d/attachment-0040.html From florianmanschwetus at gmx.de Sat Aug 9 00:45:43 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Sat, 09 Aug 2008 08:45:43 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4899667C.6010706@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> Message-ID: <489D3D17.9090209@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >> Florian Manschwetus wrote: >>> Ok, sounds fine for the receiving problem. >>> But why i have to wait after each byte when sending a command squence? >>> (the for loop in send command) >> >> Hi Florian, >> I'd imagine you probably don't! You could send all bytes in one go and >> RXTX would send them. The problem is most probably the other end: >> perhaps it has a really small buffer, some non-standard UART, or a >> crazy timing issue. If you attach a terminal to your output and send >> all the bytes of a command in one go they should appear no problem. >> >> Regards, >> Michael Erskine. >> > correct with a terminal on the other end it works, my idea was that this > basic baud has some influence. Could some one explain what it is for? > > Florian To make it more clear, my problem is that i can't use: outputStream.write(byte[]); => Beamer doesn't understand the sequence. (mostly no answer when he answers then *001) when i use this construct instead: for (int i = 0; i < command.length; i++) { this.outputStream.write(command[i]); try { Thread.sleep(25); } catch (InterruptedException e) { // TODO Auto-generated catch block e.printStackTrace(); } } it works nearly reliable. So what could it be? This Basic Baud is what exactly? Florian -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080809/692304ee/attachment-0040.bin From tjarvi at qbang.org Sat Aug 9 16:37:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Aug 2008 16:37:19 -0600 (MDT) Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489D3D17.9090209@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> <489D3D17.9090209@gmx.de> Message-ID: On Sat, 9 Aug 2008, Florian Manschwetus wrote: > Florian Manschwetus schrieb: >> Michael Erskine schrieb: >>> Florian Manschwetus wrote: >>>> Ok, sounds fine for the receiving problem. >>>> But why i have to wait after each byte when sending a command squence? >>>> (the for loop in send command) >>> >>> Hi Florian, >>> I'd imagine you probably don't! You could send all bytes in one go and >>> RXTX would send them. The problem is most probably the other end: perhaps >>> it has a really small buffer, some non-standard UART, or a crazy timing >>> issue. If you attach a terminal to your output and send all the bytes of a >>> command in one go they should appear no problem. >>> >>> Regards, >>> Michael Erskine. >>> >> correct with a terminal on the other end it works, my idea was that this >> basic baud has some influence. Could some one explain what it is for? >> >> Florian > To make it more clear, > my problem is that i can't use: > outputStream.write(byte[]); > => Beamer doesn't understand the sequence. (mostly no answer when he answers > then *001) > > when i use this construct instead: > > for (int i = 0; i < command.length; i++) { > this.outputStream.write(command[i]); > try { > Thread.sleep(25); > } catch (InterruptedException e) { > // TODO Auto-generated catch block > e.printStackTrace(); > } > } > > it works nearly reliable. > > So what could it be? This Basic Baud is what exactly? > I suspect you are using the 'moon protocol' and don't know it. RXTX enables this by default. The buffer on the other end is first in first out while reading. If the buffer is full, the bits are hand carried to the moon and burried. Then if the other side reads a couple bytes, two more bytes go into the buffer followed by more moon protocol. The resulting array of bytes the other side reads may appear to be scrambled until you go to the moon, get the bits and insert them in the right place. Flow control can prevent the default moon protocol and throttles the communiation by almost writing a byte at a time as need be. Hardware flow control is preferable but software flow control should also work. Read and write can appear to hang if the other side is not connected. This is why we don't enable them all the time. If you can't use flow control, you have to take care with the moon protocol and give the other side time to read. That is what your slower version of write is doing. -- Trent Jarvi tjarvi at qbang.org From rxtx at allenjb.me.uk Mon Aug 11 08:06:36 2008 From: rxtx at allenjb.me.uk (AllenJB) Date: Mon, 11 Aug 2008 15:06:36 +0100 Subject: [Rxtx] Disabling EV_RXFLAG Message-ID: <48A0476C.2090800@allenjb.me.uk> Hi all, I'm working with a device which does not use an EvtChar and need to disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an event mask of FD 01 00 00. The reference software I have uses FB 00 00 00. With the rxtx mask I get framing errors which I believe are caused when the EvtChar is received. Is there currently a way with rxtx (I've using rxtx from Java) to disable EV_RXFLAG? If not from Java, where would I start if I wanted to turn the EV_RXFLAG option off in the C code? I've had a grep of the rxtx source code, but I can't see where EV_RXFLAG is being set. Thanks in advance, AllenJB From tjarvi at qbang.org Mon Aug 11 14:17:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Aug 2008 14:17:27 -0600 (MDT) Subject: [Rxtx] Disabling EV_RXFLAG In-Reply-To: <48A0476C.2090800@allenjb.me.uk> References: <48A0476C.2090800@allenjb.me.uk> Message-ID: On Mon, 11 Aug 2008, AllenJB wrote: > Hi all, > > I'm working with a device which does not use an EvtChar and need to > disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an > event mask of FD 01 00 00. The reference software I have uses FB 00 00 > 00. With the rxtx mask I get framing errors which I believe are caused > when the EvtChar is received. > > Is there currently a way with rxtx (I've using rxtx from Java) to > disable EV_RXFLAG? > > If not from Java, where would I start if I wanted to turn the EV_RXFLAG > option off in the C code? I've had a grep of the rxtx source code, but I > can't see where EV_RXFLAG is being set. > > Thanks in advance, > > AllenJB Hi Allen, I'd look at termios.c::tcsetattr() and termios.c::FillDCB() -- Trent Jarvi tjarvi at qbang.org From superdadusa at gmail.com Tue Aug 12 13:57:32 2008 From: superdadusa at gmail.com (John Choi) Date: Tue, 12 Aug 2008 13:57:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. Message-ID: Hi all, Just let you all know I just start to learn Java. I have download the serial comm package and the source code from open source communities.. I was able to verify with the given message string via serial monitor. when the given message string sends to the serial port then the character return added to the end of string by default if I use "Hello World" however if I changed to something else other than "Hello, World" there is no character return add to the end of string. I thing the library download from rxtx.org has implemented for the special strings. I can do like "login\n" in the string message to make character return but I don't want to add this individual custom character for each command return in every static message string I send, Can any who have done this might help me? Basically, something like this,, Write and add function to the program write a command, Reads the respond from a serial device.. Function handles multiple messages, Write: "com open" Read: Welcome to my world" expected Write: "admin" Read: Password?, expected Write: "admin" Read: you are successfully login terminal, expected. And I need to add a separate function handler handles a character return add to the each command above. If anyone can help this I can do the reset? Thank you in advance, John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0036.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SerialIO.java Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0036.pl From Steffen.DETTMER at ingenico.com Wed Aug 13 02:16:38 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 13 Aug 2008 10:16:38 +0200 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: References: Message-ID: <20080813081638.GA25412@elberon.bln.de.ingenico.com> * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > I can do like "login\n" in the string message to make character > return but I don't want to add this individual custom character > for each command return in every static message string I send, and why not?! > Can any who have done this might help me? what's about with writing a small wrapper function adding the carriage return? However, this would be slow, because either you call write two times (very bad) or the string needs to be copied, \n appended and written (since you are using Java Performance probably isn't so critical). Personally I would write `"login\n"' and `username + "\n"' etc., because since it is part of the command it should be part of the command definition string. > Basically, something like this,, Write and add function to the program write > a command, Reads the respond from a serial device.. correctly reading a `line' is more difficult. If you cannot make assumptions about timeouts and/or you need to have low delay, you need to read byte wise. If you need to save CPU resources you might need to add some buffering layer that you can read byte-wise but that is reading blockwise with some small timeout (lets say for serial lines something around byte transmission time times three or so). > /* > * To change this template, choose Tools | Templates > * and open the template in the editor. > */ :) > package joliba; > > /** > * > * @author root > */ :) > // derived from SUN's examples in the javax.comm package > import java.io.*; > import java.util.*; > //import javax.comm.*; // for SUN's serial/parallel port libraries > import gnu.io.*; // for rxtxSerial library > > public class SerialIO implements Runnable, SerialPortEventListener { > static CommPortIdentifier portId; > static CommPortIdentifier saveportId; > static Enumeration portList; > InputStream inputStream; > SerialPort serialPort; > Thread readThread; You need a thread for your synchronous RPC-style protocol? > static String messageString = "Hello, world!"; > static OutputStream outputStream; > static boolean outputBufferEmptyFlag = false; > > public static void main(String[] args) { > boolean portFound = false; > String defaultPort; > > // determine the name of the serial port on several operating systems > String osname = System.getProperty("os.name","").toLowerCase(); > if ( osname.startsWith("windows") ) { > // windows > defaultPort = "COM1"; > } else if (osname.startsWith("linux")) { > // linux > defaultPort = "/dev/ttyS0"; > } else if ( osname.startsWith("mac") ) { > // mac > defaultPort = "????"; > } else { > System.out.println("Sorry, your operating system is not supported"); > return; > } Is such a construction recommended? Isn't there some abstraction (like COM1 working on any platform)? [...] > try { > // activate the OUTPUT_BUFFER_EMPTY notifier > serialPort.notifyOnOutputEmpty(true); > } catch (Exception e) { > System.out.println("Error setting event notification"); > System.out.println(e.toString()); > System.exit(-1); > } I doubt that -1 is defined, probably some 127 or so would be the result, maybe better simply `throw e'? > public void writetoport() { > System.out.println("Writing \""+messageString+"\" to "+serialPort.getName()); > try { > // write string to serial port > outputStream.write(messageString.getBytes()); > } catch (IOException e) {} > } maybe something like /** * Writes the given output string and an additional carriage * return to the current outputStream. */ public void writeStringToPort( /** The output string (without CR). */ String output ) throws IOException { String outputLine = output + "\n"; outputStream.write(outputLine.getBytes()); } ? > > public SerialIO() { > // initalize serial port > try { > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > } catch (PortInUseException e) {} if the port is in use, you continue? Wonder that this works in Java, I would assume serialPort beeing uninitialized which AFAIK is an error in Java. > try { > inputStream = serialPort.getInputStream(); > } catch (IOException e) {} > > try { > serialPort.addEventListener(this); > } catch (TooManyListenersException e) {} > > // activate the DATA_AVAILABLE notifier > serialPort.notifyOnDataAvailable(true); > > try { > // set port parameters > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > } catch (UnsupportedCommOperationException e) {} > > // start the read thread > readThread = new Thread(this); > readThread.start(); > > } I think in all those exception cases you can abort, because it is unlikely that ignoring those errors allow a successful continuation, so in this case maybe it would be better to add a throw clause to the method. > public void run() { > // first thing in the thread, we initialize the write operation > initwritetoport(); > try { > while (true) { > // write string to port, the serialEvent will read it > writetoport(); > Thread.sleep(1000); > } > } catch (InterruptedException e) {} > } Does this make sense? Your `SimpleReadApp' writes one and the same string each second? > public void serialEvent(SerialPortEvent event) { > switch (event.getEventType()) { > case SerialPortEvent.BI: > case SerialPortEvent.OE: > case SerialPortEvent.FE: > case SerialPortEvent.PE: > case SerialPortEvent.CD: > case SerialPortEvent.CTS: > case SerialPortEvent.DSR: > case SerialPortEvent.RI: > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > break; > case SerialPortEvent.DATA_AVAILABLE: > // we get here if data has been received > byte[] readBuffer = new byte[20]; > try { > // read data > while (inputStream.available() > 0) { > int numBytes = inputStream.read(readBuffer); > } > // print data > String result = new String(readBuffer); > System.out.println("Read: "+result); > } catch (IOException e) {} I doubt that this is correct. I would assume you will get a 20 bytes result always, if more bytes would be available they would be printed in a second line but if less bytes are read I'd assume that the buffer/result contains zero bytes from implicite readBuffer contents initialisation (zero is no string terminator in Java AFAIK). > break; > } > } > } oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From florianmanschwetus at gmx.de Wed Aug 13 06:09:31 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 13 Aug 2008 14:09:31 +0200 Subject: [Rxtx] someone has seen such errors? Message-ID: <48A2CEFB.90007@gmx.de> I mean my communication mostly works, but it is far from perfect could this be the reason? Florian Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/949b9947/attachment-0036.bin From superdadusa at gmail.com Wed Aug 13 08:40:32 2008 From: superdadusa at gmail.com (John Choi) Date: Wed, 13 Aug 2008 08:40:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: <20080813081638.GA25412@elberon.bln.de.ingenico.com> References: <20080813081638.GA25412@elberon.bln.de.ingenico.com> Message-ID: Thank you so much Steffen and I will try that suggestion. John On 8/13/08, Steffen DETTMER wrote: > > * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > > I can do like "login\n" in the string message to make character > > return but I don't want to add this individual custom character > > for each command return in every static message string I send, > > and why not?! > > > Can any who have done this might help me? > > what's about with writing a small wrapper function adding the > carriage return? > However, this would be slow, because either you call write two > times (very bad) or the string needs to be copied, \n appended > and written (since you are using Java Performance probably isn't > so critical). > > Personally I would write `"login\n"' and `username + "\n"' etc., > because since it is part of the command it should be part of the > command definition string. > > > Basically, something like this,, Write and add function to the program > write > > a command, Reads the respond from a serial device.. > > correctly reading a `line' is more difficult. If you cannot make > assumptions about timeouts and/or you need to have low delay, you > need to read byte wise. If you need to save CPU resources you > might need to add some buffering layer that you can read > byte-wise but that is reading blockwise with some small timeout > (lets say for serial lines something around byte transmission > time times three or so). > > > /* > > * To change this template, choose Tools | Templates > > * and open the template in the editor. > > */ > > :) > > > package joliba; > > > > /** > > * > > * @author root > > */ > > :) > > > // derived from SUN's examples in the javax.comm package > > import java.io.*; > > import java.util.*; > > //import javax.comm.*; // for SUN's serial/parallel port libraries > > import gnu.io.*; // for rxtxSerial library > > > > public class SerialIO implements Runnable, SerialPortEventListener { > > static CommPortIdentifier portId; > > static CommPortIdentifier saveportId; > > static Enumeration portList; > > InputStream inputStream; > > SerialPort serialPort; > > Thread readThread; > > You need a thread for your synchronous RPC-style protocol? > > > static String messageString = "Hello, world!"; > > static OutputStream outputStream; > > static boolean outputBufferEmptyFlag = false; > > > > public static void main(String[] args) { > > boolean portFound = false; > > String defaultPort; > > > > // determine the name of the serial port on several operating > systems > > String osname = System.getProperty("os.name","").toLowerCase(); > > if ( osname.startsWith("windows") ) { > > // windows > > defaultPort = "COM1"; > > } else if (osname.startsWith("linux")) { > > // linux > > defaultPort = "/dev/ttyS0"; > > } else if ( osname.startsWith("mac") ) { > > // mac > > defaultPort = "????"; > > } else { > > System.out.println("Sorry, your operating system is not > supported"); > > return; > > } > > Is such a construction recommended? Isn't there some abstraction > (like COM1 working on any platform)? > > [...] > > try { > > // activate the OUTPUT_BUFFER_EMPTY notifier > > serialPort.notifyOnOutputEmpty(true); > > } catch (Exception e) { > > System.out.println("Error setting event notification"); > > System.out.println(e.toString()); > > System.exit(-1); > > } > > I doubt that -1 is defined, probably some 127 or so would be the > result, maybe better simply `throw e'? > > > public void writetoport() { > > System.out.println("Writing \""+messageString+"\" to > "+serialPort.getName()); > > try { > > // write string to serial port > > outputStream.write(messageString.getBytes()); > > } catch (IOException e) {} > > } > > maybe something like > > /** > * Writes the given output string and an additional carriage > * return to the current outputStream. > */ > public void > writeStringToPort( > /** The output string (without CR). */ > String output > ) throws IOException > { > String outputLine = output + "\n"; > outputStream.write(outputLine.getBytes()); > } > > ? > > > > > public SerialIO() { > > // initalize serial port > > try { > > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > > } catch (PortInUseException e) {} > > if the port is in use, you continue? Wonder that this works in > Java, I would assume serialPort beeing uninitialized which AFAIK > is an error in Java. > > > try { > > inputStream = serialPort.getInputStream(); > > } catch (IOException e) {} > > > > try { > > serialPort.addEventListener(this); > > } catch (TooManyListenersException e) {} > > > > // activate the DATA_AVAILABLE notifier > > serialPort.notifyOnDataAvailable(true); > > > > try { > > // set port parameters > > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > } catch (UnsupportedCommOperationException e) {} > > > > // start the read thread > > readThread = new Thread(this); > > readThread.start(); > > > > } > > I think in all those exception cases you can abort, because it is > unlikely that ignoring those errors allow a successful > continuation, so in this case maybe it would be better to add a > throw clause to the method. > > > public void run() { > > // first thing in the thread, we initialize the write operation > > initwritetoport(); > > try { > > while (true) { > > // write string to port, the serialEvent will read it > > writetoport(); > > Thread.sleep(1000); > > } > > } catch (InterruptedException e) {} > > } > > Does this make sense? Your `SimpleReadApp' writes one and the > same string each second? > > > public void serialEvent(SerialPortEvent event) { > > switch (event.getEventType()) { > > case SerialPortEvent.BI: > > case SerialPortEvent.OE: > > case SerialPortEvent.FE: > > case SerialPortEvent.PE: > > case SerialPortEvent.CD: > > case SerialPortEvent.CTS: > > case SerialPortEvent.DSR: > > case SerialPortEvent.RI: > > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > > break; > > case SerialPortEvent.DATA_AVAILABLE: > > // we get here if data has been received > > byte[] readBuffer = new byte[20]; > > try { > > // read data > > while (inputStream.available() > 0) { > > int numBytes = inputStream.read(readBuffer); > > } > > // print data > > String result = new String(readBuffer); > > System.out.println("Read: "+result); > > } catch (IOException e) {} > > I doubt that this is correct. I would assume you will get a 20 > bytes result always, if more bytes would be available they would > be printed in a second line but if less bytes are read I'd assume > that the buffer/result contains zero bytes from implicite > readBuffer contents initialisation (zero is no string terminator > in Java AFAIK). > > > break; > > } > > } > > } > > oki, > > Steffen > > About Ingenico Throughout the world businesses rely on Ingenico for secure > and expedient electronic transaction acceptance. Ingenico products leverage > proven technology, established standards and unparalleled ergonomics to > provide optimal reliability, versatility and usability. This comprehensive > range of products is complemented by a global array of services and > partnerships, enabling businesses in a number of vertical sectors to accept > transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged > information. If you are not the addressee or authorized to receive this for > the addressee, you must not use, copy, disclose or take any action based on > this message or any information herein. If you have received this message in > error, please advise the sender immediately by reply e-mail and delete this > message. Thank you for your cooperation. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/73c4135c/attachment-0035.html From ajmas at sympatico.ca Sat Aug 16 07:15:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 09:15:41 -0400 Subject: [Rxtx] someone has seen such errors? In-Reply-To: <48A2CEFB.90007@gmx.de> References: <48A2CEFB.90007@gmx.de> Message-ID: <43B5E8DA-1D93-4D90-809B-AAF35FF724C5@sympatico.ca> On 13-Aug-08, at 08:09 , Florian Manschwetus wrote: > I mean my communication mostly works, but it is far from perfect > could this be the reason? > > Florian > > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control Judging by the error messages this looks related to the driver you are using. Do a search for the following string with you favourite search engine, it should turn up a few hits: ftdi_set_termios FAILED to set databits/stopbits/parity Andre From ajmas at sympatico.ca Sat Aug 16 19:12:04 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 21:12:04 -0400 Subject: [Rxtx] Using SerialPortEvent? Message-ID: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Hi, Could someone tell me how I should be using the SerialPortEvent? Am I meant to be waiting for data and then simply reading from the inputstream? If this is the case why no just block on an inputstream read? Andr? From tjarvi at qbang.org Sat Aug 16 19:41:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 16 Aug 2008 19:41:13 -0600 (MDT) Subject: [Rxtx] Using SerialPortEvent? In-Reply-To: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> References: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Message-ID: On Sat, 16 Aug 2008, Andre-John Mas wrote: > Hi, > > Could someone tell me how I should be using the SerialPortEvent? Am I > meant to be waiting for data and then simply reading from the > inputstream? If this is the case why no just block on an inputstream > read? > Polling for data is fine also. It really depends upon what you are trying to do. For instance, if you require x bytes before reading, you can start polling after data is available. If you read on the same thread as your GUI and are waiting for data in a read, the results may be less than desirable. Java programming is 'usually' event driven rather than polling based. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sat Aug 16 20:10:39 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 22:10:39 -0400 Subject: [Rxtx] Using SerialPortEvent? In-Reply-To: References: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Message-ID: <3E495D4C-BB28-4845-A6AB-984C9A826BDF@sympatico.ca> On 16-Aug-08, at 21:41 , Trent Jarvi wrote: > On Sat, 16 Aug 2008, Andre-John Mas wrote: > >> Hi, >> >> Could someone tell me how I should be using the SerialPortEvent? Am I >> meant to be waiting for data and then simply reading from the >> inputstream? If this is the case why no just block on an inputstream >> read? >> > > Polling for data is fine also. It really depends upon what you are > trying to do. For instance, if you require x bytes before reading, > you can start polling after data is available. If you read on the > same thread as your GUI and are waiting for data in a read, the > results may be less than desirable. > > Java programming is 'usually' event driven rather than polling based. Sounds good. I thought I would use this opportunity to provide a event based version of the TwoWaySerialComm example. Could you just validate it before I add it to the Wiki: package ajmas74.experimental; import gnu.io.CommPort; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; import gnu.io.SerialPortEvent; import gnu.io.SerialPortEventListener; import java.io.IOException; import java.io.InputStream; import java.io.OutputStream; /** * This version of the TwoWaySerialComm example makes use of the * SerialPortEventListener to avoid polling. * * @author ajmas * */ public class TwoWaySerialComm { public TwoWaySerialComm() { super(); } void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { CommPort commPort = portIdentifier.open(this.getClass().getName(),2000); if ( commPort instanceof SerialPort ) { SerialPort serialPort = (SerialPort) commPort; serialPort .setSerialPortParams (57600 ,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); (new Thread(new SerialWriter(out))).start(); serialPort.addEventListener(new SerialReader(in)); } else { System.out.println("Error: Only serial ports are handled by this example."); } } } /** * Handles the input coming from the serial port. A new line character * is treated as the end of a block in this example. */ public static class SerialReader implements SerialPortEventListener { private InputStream in; private byte[] buffer = new byte[1024]; public SerialReader ( InputStream in ) { this.in = in; } public void serialEvent(SerialPortEvent arg0) { int data; try { int len = 0; while ( ( data = in.read()) > -1 ) { if ( data != '\n' ) { break; } buffer[len++] = (byte) data; } System.out.print(new String(buffer,0,len)); } catch ( IOException e ) { e.printStackTrace(); System.exit(-1); } } } /** */ public static class SerialWriter implements Runnable { OutputStream out; public SerialWriter ( OutputStream out ) { this.out = out; } public void run () { try { int c = 0; while ( ( c = System.in.read()) > -1 ) { this.out.write(c); } } catch ( IOException e ) { e.printStackTrace(); System.exit(-1); } } } public static void main ( String[] args ) { try { (new TwoWaySerialComm()).connect("COM3"); } catch ( Exception e ) { e.printStackTrace(); } } } From lfarkas at lfarkas.org Tue Aug 19 07:32:59 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Tue, 19 Aug 2008 15:32:59 +0200 Subject: [Rxtx] JNI or CNI Message-ID: <48AACB8B.9060606@lfarkas.org> hi, what is the current recommended way to rxtx on linux JNI or it's better to use CNI? is the CNI version fully functional and the same level as the JNI? i currently try to make a rhel/centos/fedora rpm for rxtx but has many problems with the standard dir structure. yours. -- Levente "Si vis pacem para bellum!" From lfarkas at lfarkas.org Tue Aug 19 08:47:34 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Tue, 19 Aug 2008 16:47:34 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel Message-ID: <48AADD06.7040809@lfarkas.org> hi, newer or not so newer linux kernel do not contain the UTS_RELEASE so the current rxtx is not compile on the latest kernels. even if it's commented out in the cvs configure there are other places. i attcahed a patch which fix it (or at least doesn't cause error at non-debug build). ps. is there any plan to the new 2.1-8 release in the near future? there are many changes (at least the license change in all file and in this case create a diff is very difficult)? the latest release more then 2 years old:-( -- Levente "Si vis pacem para bellum!" -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-2.1-uts.patch Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080819/ab5d38ac/attachment-0029.pl From ajmas at sympatico.ca Tue Aug 19 16:21:53 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 19 Aug 2008 18:21:53 -0400 Subject: [Rxtx] Event based example Message-ID: <24735BFB-B088-4B84-8173-FE98DF63B12F@sympatico.ca> Hi, I have just posted an example of using SerialPortEventListener in the Wiki: http://rxtx.qbang.org/wiki/index.php/Event_Based_Two_Way_Communication If you see any issues please could you let me know, or makes the changes. Andre From Martin.Oberhuber at windriver.com Fri Aug 22 04:02:24 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 22 Aug 2008 12:02:24 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <48AADD06.7040809@lfarkas.org> References: <48AADD06.7040809@lfarkas.org> Message-ID: <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> Farkas, there are indeed efforts to get a new RXTX release out the door. Your experience as a package maintainer would likely be helpful during these efforts, since I'd think it makes sense to keep the patches minimal that you must make to have the source compile in your environment. What are the things that you find problematic, apart from the UTS thing that you have mentioned before? What is the timing that you have in mind for your package? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Farkas Levente > Sent: Tuesday, August 19, 2008 4:48 PM > To: rxtx at qbang.org > Subject: [Rxtx] UTS_RELEASE not defined in newer kernel > > hi, > newer or not so newer linux kernel do not contain the > UTS_RELEASE so the > current rxtx is not compile on the latest kernels. even if it's > commented out in the cvs configure there are other places. > i attcahed a patch which fix it (or at least doesn't cause error at > non-debug build). > > ps. is there any plan to the new 2.1-8 release in the near > future? there > are many changes (at least the license change in all file and in this > case create a diff is very difficult)? the latest release more then 2 > years old:-( > > -- > Levente "Si vis pacem para bellum!" > From lfarkas at lfarkas.org Fri Aug 22 04:36:26 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Fri, 22 Aug 2008 12:36:26 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> References: <48AADD06.7040809@lfarkas.org> <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> Message-ID: <48AE96AA.6090505@lfarkas.org> hi, the packages already build for fedora-9 and centos-5 and here: http://www.lfarkas.org/linux/packages/ what i've to patch, the UTS, the configure script, but it's already fixed in the cvs (in another way) and the loadlibrary. the reasons for last one can be found here: https://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_files_that_use_JNI after we test it i'd like to add these packages to fedora and epel main repository (that's why it's be useful a new release after 2 years:-) imho versions are cheap and why not just release 2.1-8? the real code changes are minimal and if something critical bug found still can release 2.1-9:-) ps. and would be better to use simple number for version like 2.1-7 rather then 2.1-7v2. Oberhuber, Martin wrote: > Farkas, > > there are indeed efforts to get a new RXTX release out the > door. Your experience as a package maintainer would likely > be helpful during these efforts, since I'd think it makes > sense to keep the patches minimal that you must make to > have the source compile in your environment. > > What are the things that you find problematic, apart from > the UTS thing that you have mentioned before? > > What is the timing that you have in mind for your package? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >> On Behalf Of Farkas Levente >> Sent: Tuesday, August 19, 2008 4:48 PM >> To: rxtx at qbang.org >> Subject: [Rxtx] UTS_RELEASE not defined in newer kernel >> >> hi, >> newer or not so newer linux kernel do not contain the >> UTS_RELEASE so the >> current rxtx is not compile on the latest kernels. even if it's >> commented out in the cvs configure there are other places. >> i attcahed a patch which fix it (or at least doesn't cause error at >> non-debug build). >> >> ps. is there any plan to the new 2.1-8 release in the near >> future? there >> are many changes (at least the license change in all file and in this >> case create a diff is very difficult)? the latest release more then 2 >> years old:-( >> >> -- >> Levente "Si vis pacem para bellum!" >> -- Levente "Si vis pacem para bellum!" From tjarvi at qbang.org Fri Aug 22 18:50:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Aug 2008 18:50:32 -0600 (MDT) Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <48AE96AA.6090505@lfarkas.org> References: <48AADD06.7040809@lfarkas.org> <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> <48AE96AA.6090505@lfarkas.org> Message-ID: Hi Farkas, The v2 was simply the second build - no code changes. We are comming out with a new release shortly. I would encourage working with distros as you are. The building of rxtx turns out to be a bottle neck in quick releases. We do want stable releases that work for a year or more but I would have no problems with quicker cycles on developing work. I would have no problem working with someone that did builds that receive less testing more often but they do have to come out for multiple platforms from this end. Thanks for the links. On Fri, 22 Aug 2008, Farkas Levente wrote: > hi, > the packages already build for fedora-9 and centos-5 and here: > http://www.lfarkas.org/linux/packages/ > what i've to patch, the UTS, the configure script, but it's already > fixed in the cvs (in another way) and the loadlibrary. the reasons for > last one can be found here: > https://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_files_that_use_JNI > after we test it i'd like to add these packages to fedora and epel main > repository (that's why it's be useful a new release after 2 years:-) > imho versions are cheap and why not just release 2.1-8? the real code > changes are minimal and if something critical bug found still can > release 2.1-9:-) > > ps. and would be better to use simple number for version like 2.1-7 > rather then 2.1-7v2. > > Oberhuber, Martin wrote: >> Farkas, >> >> there are indeed efforts to get a new RXTX release out the >> door. Your experience as a package maintainer would likely >> be helpful during these efforts, since I'd think it makes >> sense to keep the patches minimal that you must make to >> have the source compile in your environment. >> >> What are the things that you find problematic, apart from >> the UTS thing that you have mentioned before? >> >> What is the timing that you have in mind for your package? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >>> On Behalf Of Farkas Levente >>> Sent: Tuesday, August 19, 2008 4:48 PM >>> To: rxtx at qbang.org >>> Subject: [Rxtx] UTS_RELEASE not defined in newer kernel >>> >>> hi, >>> newer or not so newer linux kernel do not contain the >>> UTS_RELEASE so the >>> current rxtx is not compile on the latest kernels. even if it's >>> commented out in the cvs configure there are other places. >>> i attcahed a patch which fix it (or at least doesn't cause error at >>> non-debug build). >>> >>> ps. is there any plan to the new 2.1-8 release in the near >>> future? there >>> are many changes (at least the license change in all file and in this >>> case create a diff is very difficult)? the latest release more then 2 >>> years old:-( >>> >>> -- >>> Levente "Si vis pacem para bellum!" >>> > > > From andy at triera.net Sat Aug 23 15:17:44 2008 From: andy at triera.net (Andy Rozman) Date: Sat, 23 Aug 2008 21:17:44 +0000 Subject: [Rxtx] port not identified on FreeBSD In-Reply-To: References: Message-ID: <48B07E78.2030306@triera.net> Hi ! I have one small problem... I have started using FreeBSD in last few days and I have come accross a problem with rxtx on FreeBSD. I am using usb-to-serial converter, which is identified under FreeBSD without problem as ucom0, and creates link under /dev called ttyU0, which is correct way to be done under FreeBSD (if device would be unidentified it would be called ugen0 - as usb generic). Problem is that I say to rxtx to get my all serial ports this one is not among them. Which names are permissable under linux-like implementations? Which will be accepted as serial ports? Andy From tjarvi at qbang.org Sat Aug 23 13:57:45 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 23 Aug 2008 13:57:45 -0600 (MDT) Subject: [Rxtx] port not identified on FreeBSD In-Reply-To: <48B07E78.2030306@triera.net> References: <48B07E78.2030306@triera.net> Message-ID: On Sat, 23 Aug 2008, Andy Rozman wrote: > Hi ! > > I have one small problem... I have started using FreeBSD in last few > days and I have come accross a problem with rxtx on FreeBSD. > > I am using usb-to-serial converter, which is identified under FreeBSD > without problem as ucom0, and creates link under /dev called > ttyU0, which is correct way to be done under FreeBSD (if device would be > unidentified it would be called ugen0 - as usb generic). Problem is that > I say to rxtx to get my all serial ports this one is not among them. > Which names are permissable under linux-like implementations? Which will > be accepted as serial ports? > > Andy > Thanks Andy! We will add ttyU* to FreeBSD. For now you can use properties to enable the port. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting#How_does_rxtx_detect_ports.3F__Can_I_override_it.3F The fix: diff -u -r1.16.2.59 RXTXCommDriver.java --- RXTXCommDriver.java 18 Nov 2007 22:32:41 -0000 1.16.2.59 +++ RXTXCommDriver.java 23 Aug 2008 19:55:25 -0000 @@ -644,6 +644,7 @@ { String[] Temp = { "ttyd", //general purpose serial ports + "ttyU", //general purpose USB serial ports "cuaa", //dialout serial ports "ttyA", //Specialix SI/XIO dialin ports "cuaA", //Specialix SI/XIO dialout ports -- Trent Jarvi tjarvi at qbang.org From rick_knight at rlknight.com Mon Aug 4 13:25:10 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Mon, 04 Aug 2008 12:25:10 -0700 Subject: [Rxtx] Sun's Comm API? Message-ID: <48975796.4010600@rlknight.com> I have an application that requires the javax compatible version of RXTX and Sun's comm api. I've been able to download and extract the version of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api anywhere. Can someone tell me where I can find it? Or maybe send me a copy? Also, when I try to build RXTX, configure and make complete successfully but make install failes with this error libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 I've never come accross this error before. How can I get past it? Thanks, Rick From bboyes at systronix.com Mon Aug 4 19:10:01 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:10:01 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48975796.4010600@rlknight.com> References: <48975796.4010600@rlknight.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/cb9c6167/attachment-0045.html From bboyes at systronix.com Mon Aug 4 19:12:37 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:12:37 -0600 Subject: [Rxtx] Towards an RXTX release - CSR BT/USB chipset In-Reply-To: <488FB7E7.8000802@gmail.com> References: <460801A4097E3D4CA04CC64EE648584806C56CF0@ism-mail03.corp.ad.wrs.com> <13557-75390@sneakemail.com> <20980-23424@sneakemail.com> <488FB7E7.8000802@gmail.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/52236088/attachment-0045.html From tjarvi at qbang.org Mon Aug 4 19:42:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 19:42:21 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: On Mon, 4 Aug 2008, Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: > I have an application that requires the javax compatible > version of RXTX > and Sun's comm api. I've been able to download and extract > the version > of RXTX that I need (2.0-7pre2) but I can't find Sun's camm > api > anywhere. Can someone tell me where I can find it? Or maybe > send me a > > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm port > support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have just > a ZIP with only the .class JAR file - no source or docs), has a readme > with these comments: > > This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release.? The 2.0.3 release itself is > no longer distributed.? comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project.? The RxTx project (http://www.rxtx.org ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org) was opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support.? Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins.? Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > ? > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > I hope that is helpful! > It would be nice to work with Sun to resolve those longstanding issues. But it may not be practical unless the process goes as fast and painless as the grandfathering of commapi did. Another option may be the old kaffe extensions that moved to gnu classpathx. These don't have the native libraries but should provide the 2.0 interface and the javax.comm.properties mechansim for SPI. http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Mon Aug 4 20:23:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Mon, 04 Aug 2008 20:23:57 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4897B9BD.5070809@ergotech.com> Has there been any work/would it be possible, to layer a javacomm look-alike on top of the GNU code? The goal is not to move the javax code forward, but to emulate the "legacy" javax packages for people who still need this. Jim Trent Jarvi wrote: > On Mon, 4 Aug 2008, Bruce Boyes wrote: > >> At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible >> version of RXTX >> and Sun's comm api. I've been able to download and extract >> the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm >> api >> anywhere. Can someone tell me where I can find it? Or maybe >> send me a >> >> >> javaxcomm has had a sort of on-again off-again history. The windoze >> version has been languishing for years (literally) but there are newer >> versions for other OS's. >> >> We try to keep links on one of our help pages current: >> http://www.practicalembeddedjava.com/tools/javatools_list.html >> which gets you to here: >> http://java.sun.com/products/javacomm/ >> where it says in fact they no longer even support Windows and Mac: >> "Implementations of the API are currently available for Solaris SPARC, >> Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so >> someone could support it. But I guess that's part of the reason RXTX >> exists! >> >> So one of Sun's own products, SunSPOT, has to use RXTX to get comm port >> support. >> >> The version we use is 2.0 from 11/15/1998. I have posted it on our >> website, which is within the terms of the license agreement contained >> therein (as I understand it). >> >> The last version of javaxcomm for Windows, 2.0.3, (for which I have just >> a ZIP with only the .class JAR file - no source or docs), has a readme >> with these comments: >> >> This distribution contains the comm.jar file original part >> of the COMMAPI 2.0.3 release. The 2.0.3 release itself is >> no longer distributed. comm.jar, which contains the comm >> API java class files (eg. Sun's binary implementation of the >> interface classes), is being made available, unsupported, >> with no obligation to fix bugs, at the request of the RXTX >> project. The RxTx project (http://www.rxtx.org ), uses the >> comm.jar class files, but provides their own native library >> components to provide support for other platforms. >> >> The 2.0.3 comm.jar is being provided in this way because >> as of COMMAPI 3.x, the java binary implementation forked and >> became incompatible with the RxTx project's native code. >> Due to the lack of a clear business case, and to resource >> constraints, no additional resources are being >> provided to provide an alternative engineering solution >> at the time of writing. >> >> RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: >> >> Ultimately the COMMAPI would be better served if a Java >> Community Process JSR (http://www.jcp.org) was opened and >> the COMMAPI was rearchitected to provide a more pluggable >> framework to improve cross-platform support. Such an >> architecture would embody a better defined and better >> documented SPI interface, including a way for comm. ports >> to be revealed to the client application through the API >> via platform-aware plugins. Similarly, native code used >> to access comm port in general could be handled more >> flexibly using a plugin model, whereby on any platform, >> multiple native modules could be in use simultaneously. >> >> Since there are now various ways serial ports can be implemented >> and accessed, modular comm. port JNI native libraries would be >> of benefit insofar as removing the burden of over-generalization >> from any single native component, or inversely, by relieving the >> implicit constraint that comm. drivers be accessed only via a >> monolithic mechanism, such as the UNIX vnode interface. >> >> paul.klissner at sun.com >> 6/10/06 >> >> I hope that is helpful! >> > > It would be nice to work with Sun to resolve those longstanding issues. > But it may not be practical unless the process goes as fast and painless > as the grandfathering of commapi did. > > Another option may be the old kaffe extensions that moved to gnu > classpathx. These don't have the native libraries but should provide > the 2.0 interface and the javax.comm.properties mechansim for SPI. > > http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Mon Aug 4 21:09:15 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 21:09:15 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? Message-ID: Hi Jim, I will not step into the javax.comm namespace without Sun's explicite permission. I fully understand the pain point you are trying to address. In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm Linux) - which remains an integral part of rxtx. At the time it was a win for Sun and rxtx. The Sun commapi license is/was fairly clear that rxtx should not step into that namespace. It made sense as Sun was active in that space and rxtx may go into another namespace - it was an experiment in working with Sun. This may sound silly looking at something that happened almost 10 years ago. In a community of respect which Sun helped create, there is no question about what to do. I hope eventually Sun will step up and do a right thing too. I agree that this is hurting the API more than helping it. There are also questions about how to replace the API in the long term which includes HID support which isn't going well so far. Others that can't even look at Sun's javax.comm today and can look at Kaffe's contribution to classpathx can easily work around such restrictions. On Mon, 4 Aug 2008, Jim Redman wrote: > Has there been any work/would it be possible, to layer a javacomm > look-alike on top of the GNU code? > > The goal is not to move the javax code forward, but to emulate the > "legacy" javax packages for people who still need this. > > Jim > > Trent Jarvi wrote: >> >> It would be nice to work with Sun to resolve those longstanding issues. >> But it may not be practical unless the process goes as fast and painless >> as the grandfathering of commapi did. >> >> Another option may be the old kaffe extensions that moved to gnu >> classpathx. These don't have the native libraries but should provide >> the 2.0 interface and the javax.comm.properties mechansim for SPI. >> >> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From florianmanschwetus at gmx.de Tue Aug 5 05:04:46 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 13:04:46 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: References: <48971C1F.9020806@gmx.de> Message-ID: <489833CE.1040801@gmx.de> Just look at sendCommand in this method I have to place a Thread.sleep(20) after each byte send to get working. Even the event based receive doesn't work fine but this could be may stupidness. The specifikation document (it is on the last pages of the manual) for the beamer could be found on: http://www.optoma.co.uk/support.aspx Florian Manschwetus Trent Jarvi schrieb: > > Hi Florian > > Sorry for the top post in advance. I worry you may not see my answer > under all your code :) > > I have not received this email before. This is 500k of code which I > don't have time to read. I can spend about 5 min on each hobby email > and still get to work in the morning. I have a couple suggestions for > how to get an answer. > > First, cut out your comments and extra code so you can demonstrate the > question (I might even glance and see what is wrong then). Don't go for > a working final product. Isolate the problem using a simple program and > then ask with that as an example. If I did what you just did, I'd have > to post 3/4 of a million lines of code :) > > Second, join the rxtx mail-list and ask there. This will give you 100x > more eyes. I'll also read and try to follow. > > -- > taj > > > > On Mon, 4 Aug 2008, Florian Manschwetus wrote: > >> It could be that my university account is blocked by filters so >> resending from here. >> >> >> Topic is to control Optoma HD80 beamer using rs232 serial chat. >> This code is able to detect power state and switch the beamer on / off. >> connected is the beamer using a digitus usb 2.0 serial adapter with an >> FT232 USB-Serial adapter the systems architecture is amd64. >> >> Please take a look in the sendCommand routine i have to place theire >> those Thread.sleep to get it working. >> Now the question is this correct or is there a better way to get this >> working correctly? >> >> In the javadoc coming with the install i found this: >> setBaudBase >> >> public boolean setBaudBase(int BaudBase) >> throws UnsupportedCommOperationException, >> java.io.IOException >> >> Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 >> before using. >> >> could this explain the error? >> I attached my java source and the protocol description for the beamer >> (available on vendor website). >> >> thx, >> Florian Manschwetus >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: TestRS232.java Type: text/x-java Size: 9143 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0090.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0091.bin From michael.erskine at ketech.com Tue Aug 5 05:53:49 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Tue, 5 Aug 2008 12:53:49 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489833CE.1040801@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> > Just look at sendCommand in this method I have to place a > Thread.sleep(20) after each byte send to get working. Even the event > based receive doesn't work fine but this could be may stupidness. Hi Florian, Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. Regards, Michael Erskine. From florianmanschwetus at gmx.de Tue Aug 5 07:28:15 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:28:15 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> Message-ID: <4898556F.8000208@gmx.de> Michael Erskine schrieb: >> Just look at sendCommand in this method I have to place a >> Thread.sleep(20) after each byte send to get working. Even the event >> based receive doesn't work fine but this could be may stupidness. > > Hi Florian, > > Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. > > Regards, > Michael Erskine. > Ok, sounds fine for the receiving problem. But why i have to wait after each byte when sending a command squence? (the for loop in send command) Florian > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/284f350c/attachment-0044.bin From florianmanschwetus at gmx.de Tue Aug 5 07:44:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:44:14 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <4898592E.2020908@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >>> Just look at sendCommand in this method I have to place a >>> Thread.sleep(20) after each byte send to get working. Even the event >>> based receive doesn't work fine but this could be may stupidness. >> >> Hi Florian, >> >> Yes, naturally you'll have to wait for a response from the other end. >> Why not wait for notification from the event thread perhaps using a >> BlockingDeque rather than your LinkedList. Generally I >> try to decouple all input and output streams: in your case your >> application is operating synchronously like the "expect" program >> (http://expect.nist.gov/) so waits (or timeouts) will need to be >> factored in. >> >> Regards, >> Michael Erskine. >> > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) > > Florian Furthermore there is this basic baud with this confusing javadoc entry: public boolean setBaudBase(int BaudBase) throws UnsupportedCommOperationException, java.io.IOException Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 before using. maybe this could explain something Florian >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/006c7425/attachment-0044.bin From jredman at ergotech.com Tue Aug 5 09:13:36 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 05 Aug 2008 09:13:36 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: Message-ID: <48986E20.3060104@ergotech.com> Trent, So two issues: 1) Technically I'm still not sure how easy/practical a layer would be. The problems are always classes like listeners, and wrapping returns of gnu.io classes. I really see it as a "delegate" type of concept. Any thoughts or ideas of the practicality of this approach? The idea is not to modify RXTX. 2) Javax. The javax namespace does seem to be in widespread use outside of Sun (the same is true for the java namespace). The classpath extensions, or some other location, should be interested in a JavaComm implementation even if it does have dependencies on RXTX. Would you have any philosophical objection to an approach like that? Of course, I suspect it might be better if someone with that authority at Sun would admit that the javax namespace is already in the wild and that there is no problem with it being used within RXTX. Jim Trent Jarvi wrote: > Hi Jim, > > I will not step into the javax.comm namespace without Sun's explicite > permission. I fully understand the pain point you are trying to address. > > In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm > Linux) - which remains an integral part of rxtx. At the time it was a win for > Sun and rxtx. > > The Sun commapi license is/was fairly clear that rxtx should not step into that > namespace. It made sense as Sun was active in that space and rxtx may go into > another namespace - it was an experiment in working with Sun. > > This may sound silly looking at something that happened almost 10 years ago. > In a community of respect which Sun helped create, there is no question about > what to do. I hope eventually Sun will step up and do a right thing too. > > I agree that this is hurting the API more than helping it. There are also > questions about how to replace the API in the long term which includes HID > support which isn't going well so far. > > Others that can't even look at Sun's javax.comm today and can look at Kaffe's > contribution to classpathx can easily work around such restrictions. > > On Mon, 4 Aug 2008, Jim Redman wrote: > >> Has there been any work/would it be possible, to layer a javacomm >> look-alike on top of the GNU code? >> >> The goal is not to move the javax code forward, but to emulate the >> "legacy" javax packages for people who still need this. >> >> Jim >> >> Trent Jarvi wrote: >>> It would be nice to work with Sun to resolve those longstanding issues. >>> But it may not be practical unless the process goes as fast and painless >>> as the grandfathering of commapi did. >>> >>> Another option may be the old kaffe extensions that moved to gnu >>> classpathx. These don't have the native libraries but should provide >>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>> >>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From sandeep at genevasoftech.com Tue Aug 5 11:18:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Tue, 05 Aug 2008 22:48:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <48988B6C.5080409@genevasoftech.com> Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. *-- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/ad20f1cb/attachment-0044.html From Martin.Oberhuber at windriver.com Tue Aug 5 13:30:17 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Tue, 5 Aug 2008 21:30:17 +0200 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Sandeep, shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on Sol7 but I've successfully run it on Sol9 and Sol10. Or is your request really about a native 64bit variant? I'm afraid that then you're out of luck since I think that quite a bit of RXTX is not yet ready for 64 bit. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Sandeep Kumar K Sent: Tuesday, August 05, 2008 7:19 PM To: rxtx at qbang.org Subject: [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so for Solaris 9 Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. -- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/81b7f988/attachment-0044.html From tjarvi at qbang.org Tue Aug 5 22:38:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 22:38:34 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 5 Aug 2008, Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built > on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid that > then > you're out of luck since I think that quite a bit of RXTX is not yet > ready > for 64 bit. > While rxtx-2.1-7 probably has problems, The CVS code should be OK for 64 bit Solaris. If it isn't, let me know and I'll find which patch is missing. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Aug 5 23:13:00 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 23:13:00 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48986E20.3060104@ergotech.com> References: <48986E20.3060104@ergotech.com> Message-ID: On Tue, 5 Aug 2008, Jim Redman wrote: > Trent, > > So two issues: > > 1) Technically I'm still not sure how easy/practical a layer would be. The > problems are always classes like listeners, and wrapping returns of gnu.io > classes. I really see it as a "delegate" type of concept. Any thoughts or > ideas of the practicality of this approach? The idea is not to modify RXTX. I have not put too much thought into this. I assume you want what rxtx 2.0 provided to tie into javax.comm implementations. More classes could be added to rxtx 2.1-7 for SPI support. Maintaining rxtx-2.0 could also be handed to someone if they like. > > 2) Javax. The javax namespace does seem to be in widespread use outside of > Sun (the same is true for the java namespace). The classpath extensions, or > some other location, should be interested in a JavaComm implementation even > if it does have dependencies on RXTX. Would you have any philosophical > objection to an approach like that? > No problems. Classpathx would be a possible place to do it. I'd suggest thinking twice about what this involves in practical terms. You would be wanting to revive the 2.0 API while Sun is at 3.0 and grandfathering the JSR. This undermines the main reason (established api) for using the javax.comm namespace and does not leave such a project in a good position. The only win I see here is maintaining support for applications that can't migrate namespaces. Not that that isn't important. At some point it is going to be less work to just edit the bytecode :) Such a javax.comm effort would also be signing up new projects that decided to use the work up for concerns they probably will not understand or expect. That probably isn't a good path to facilitate for new projects at this time. We will put a good faith effort to work well with others but keep in mind the project has limited bandwidth for such efforts. > Of course, I suspect it might be better if someone with that authority at Sun > would admit that the javax namespace is already in the wild and that there is > no problem with it being used within RXTX. > > Jim > > Trent Jarvi wrote: >> Hi Jim, >> >> I will not step into the javax.comm namespace without Sun's explicite >> permission. I fully understand the pain point you are trying to address. >> >> In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java >> Comm Linux) - which remains an integral part of rxtx. At the time it was a >> win for Sun and rxtx. >> >> The Sun commapi license is/was fairly clear that rxtx should not step into >> that namespace. It made sense as Sun was active in that space and rxtx may >> go into another namespace - it was an experiment in working with Sun. >> >> This may sound silly looking at something that happened almost 10 years >> ago. In a community of respect which Sun helped create, there is no >> question about what to do. I hope eventually Sun will step up and do a >> right thing too. >> >> I agree that this is hurting the API more than helping it. There are also >> questions about how to replace the API in the long term which includes HID >> support which isn't going well so far. >> >> Others that can't even look at Sun's javax.comm today and can look at >> Kaffe's contribution to classpathx can easily work around such >> restrictions. >> >> On Mon, 4 Aug 2008, Jim Redman wrote: >> >>> Has there been any work/would it be possible, to layer a javacomm >>> look-alike on top of the GNU code? >>> >>> The goal is not to move the javax code forward, but to emulate the >>> "legacy" javax packages for people who still need this. >>> >>> Jim >>> >>> Trent Jarvi wrote: >>>> It would be nice to work with Sun to resolve those longstanding issues. >>>> But it may not be practical unless the process goes as fast and painless >>>> as the grandfathering of commapi did. >>>> >>>> Another option may be the old kaffe extensions that moved to gnu >>>> classpathx. These don't have the native libraries but should provide >>>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>>> >>>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From sandeep at genevasoftech.com Wed Aug 6 00:03:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Wed, 06 Aug 2008 11:33:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: <48993EB8.30107@genevasoftech.com> Thank you Mr. Martin for your suggestion. The native file which is given in rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am getting the following error . Any suggestions to solve this issue. I am using Solaris SPARC 64 bit machine. ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) thrown while loading gnu.io.RXTXCommDriver Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(Unknown Source) at java.lang.ClassLoader.loadLibrary(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) at com.ReadFromModem.main(ReadFromModem.java:84) * * *Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid > that then > you're out of luck since I think that quite a bit of RXTX is not yet ready > for 64 bit. > > Cheers, > -- > *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > ------------------------------------------------------------------------ > *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On > Behalf Of *Sandeep Kumar K > *Sent:* Tuesday, August 05, 2008 7:19 PM > *To:* rxtx at qbang.org > *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so > for Solaris 9 > > Hi, > > Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 > bit machine. The librxtxSerial.so given in website is for Solaris 8. > > *-- > > Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/1e920343/attachment-0044.html From tjarvi at qbang.org Wed Aug 6 00:21:42 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 00:21:42 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <48993EB8.30107@genevasoftech.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> <48993EB8.30107@genevasoftech.com> Message-ID: Hi Sandeep You may be out of luck unless you can compile the 2.1 src in CVS (requires gnu make and gcc). But you could try the ToyBox(R)(TM) which is a collection of WiLdLy untested cross compiled 2.1-7 binaries covering everything from the ibm z series to embeded arm/ppc. To give an idea how poorly these are tested, I don't even know if z series machines have a serial port. ftp://www.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Solaris They should at least match the binary types. Actually, I think if you use the rxtx jar from CVS with that file, it should 'work' as the fix for 64 bits was in java not the native code. You could just cd rxtx*/src; javac *.java then jar -cf RXTXcomm.jar `find -name \*.class` to create the hybrid which will complain about version information a bit. On Wed, 6 Aug 2008, Sandeep Kumar K wrote: > Thank you Mr. Martin for your suggestion. The native file which is given in > rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am > getting the following error . > Any suggestions to solve this issue. > I am using Solaris SPARC 64 bit machine. > > ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar > java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 > (Possible cause: architecture word > width mismatch) thrown while loading gnu.io.RXTXCommDriver > Exception in thread "main" java.lang.UnsatisfiedLinkError: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF > class: ELFCLASS64 (Possible cause: > architecture word width mismatch) > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(Unknown Source) > at java.lang.ClassLoader.loadLibrary(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > at com.ReadFromModem.main(ReadFromModem.java:84) > > * > * > > *Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > > > Oberhuber, Martin wrote: >> Sandeep, >> shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse >> variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on >> Sol7 but I've successfully run it on Sol9 and Sol10. >> Or is your request really about a native 64bit variant? I'm afraid that >> then >> you're out of luck since I think that quite a bit of RXTX is not yet ready >> for 64 bit. >> Cheers, >> -- >> *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> ------------------------------------------------------------------------ >> *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On >> Behalf Of *Sandeep Kumar K >> *Sent:* Tuesday, August 05, 2008 7:19 PM >> *To:* rxtx at qbang.org >> *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so >> for Solaris 9 >> >> Hi, >> >> Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 >> bit machine. The librxtxSerial.so given in website is for Solaris 8. >> >> *-- >> Thanks & Regards >> >> Sandeep Kumar K >> Sr. Software Engineer >> Geneva Software Technologies >> Whitefield, Bangalore >> Mob : 9880193454* >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> From michael.erskine at ketech.com Wed Aug 6 01:39:28 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 6 Aug 2008 08:39:28 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Florian Manschwetus wrote: > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) Hi Florian, I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. Regards, Michael Erskine. From florianmanschwetus at gmx.de Wed Aug 6 02:53:16 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 06 Aug 2008 10:53:16 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Message-ID: <4899667C.6010706@gmx.de> Michael Erskine schrieb: > Florian Manschwetus wrote: >> Ok, sounds fine for the receiving problem. >> But why i have to wait after each byte when sending a command squence? >> (the for loop in send command) > > Hi Florian, > I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. > > Regards, > Michael Erskine. > correct with a terminal on the other end it works, my idea was that this basic baud has some influence. Could some one explain what it is for? Florian > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/c2b4fa84/attachment-0044.bin From rick_knight at rlknight.com Wed Aug 6 13:01:07 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:01:07 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F4F3.3020707@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > I have an application (Readerware) that uses RXTX with Javax to access the serial port. This used to work fine under previous Linux' and Java, but something has changed, I assume with Java itself , that is causing the application to fail with a link error. The application is not able to find librxtxSerialParallel.so. RXTX supplies librxtxSerial.so and librxtxParallel.so, but not librxtxSerialParallel.so. Where can I get librxtxSerialParallel.so, or do I need it? Is something else causing the lib to not be found? Thanks, Rick Knight From rick_knight at rlknight.com Wed Aug 6 13:17:55 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:17:55 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F8E3.5060400@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Thanks for the reply. The developer of the app I'm trying to use (Readerware) has sent me a copy of the comm.api and I've copied the library (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar into the proper places. When I try to run the application, I get this error... Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: /usr/lib/libSolarisSerialParallel.so: /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not little-endian (Possible cause: endianness mismatch) Caught java.lang.UnsatisfiedLinkError: com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I while loading driver com.sun.comm.SolarisDriver Is there a way around this error? Thanks again, Rick Knight From jlar310 at gmail.com Wed Aug 6 13:37:42 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 14:37:42 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899F8E3.5060400@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > The developer of the app I'm trying to use (Readerware) has sent me a > copy of the comm.api and I've copied the library > (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar > into the proper places. When I try to run the application, I get this > error... > > Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: > /usr/lib/libSolarisSerialParallel.so: > /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not > little-endian (Possible cause: endianness mismatch) > Caught java.lang.UnsatisfiedLinkError: > com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I > > while loading driver com.sun.comm.SolarisDriver > > Is there a way around this error? What host OS are you running? From your original post it looks like 32 bit Linux. The libSolarisSerialParallel.so file is for Sun Solaris and will vary depending on the underlying hardware architecture as well. Sorry for the double post Rick, but I failed to send this to the list the first time... -- Jeff From rick_knight at rlknight.com Wed Aug 6 13:44:29 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:44:29 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: <4899FF1D.9030504@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > > >> The developer of the app I'm trying to use (Readerware) has sent me a >> copy of the comm.api and I've copied the library >> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >> into the proper places. When I try to run the application, I get this >> error... >> >> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >> /usr/lib/libSolarisSerialParallel.so: >> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >> little-endian (Possible cause: endianness mismatch) >> Caught java.lang.UnsatisfiedLinkError: >> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >> >> while loading driver com.sun.comm.SolarisDriver >> >> Is there a way around this error? >> > > What host OS are you running? From your original post it looks like 32 > bit Linux. > > The libSolarisSerialParallel.so file is for Sun Solaris and will vary > depending on the underlying hardware architecture as well. > > I'm running Kubuntu Linux (debian based). It's 32 bit. Rick Knight From jlar310 at gmail.com Wed Aug 6 15:33:23 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 16:33:23 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > I don't think Sun did binary libraries for Linux in the 2.0 version. Can someone with more historical experience than I confirm that? I recently tried to port a Comm API application from Solaris sparc to Linux x86 and likewise could not get my hands on the binary libraries. I eventually just re-wrote the code to use the gnu namespace packages and rxtx 2.1. What I don't understand is why your application vendor does not provide everything you need to run their software. FYI: I have librxtxParallel.so and librxtxSerial.so installed at JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is /usr/java/default which is actually a softlink to /usr/java/jre1.6.0_05. -- Jeff From defiantlew at yahoo.com.au Wed Aug 6 16:29:33 2008 From: defiantlew at yahoo.com.au (Lew L) Date: Thu, 7 Aug 2008 08:29:33 +1000 Subject: [Rxtx] Sun's Comm API Documentation References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> Message-ID: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> As a matter of interest is the Sun Comm API documentation available somewhere? I have tried the Sun site but it seems to have been removed. Unless I have missed the documentation for RXTX? I javadocced the RXTX source but information (to me) is minimal. Somewhere I got the impression that the Sun Comm API docs is, or was, compatible with RXTX, what is the best docs to use in conjuntion with RXTX and where may the be available? Cheers Lew From rick_knight at rlknight.com Wed Aug 6 17:18:33 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:18:33 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A3149.4050306@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff I'm not sure if I posted this here or not, but when I try to build RXTX from source I get this install error... make all-am make[1]: Entering directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' make[1]: Nothing to be done for `all-am'. make[1]: Leaving directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 Can you tell me how to get past this error and get RXTX built and installed? Thanks, Rick From bboyes at systronix.com Wed Aug 6 17:40:12 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Wed, 06 Aug 2008 17:40:12 -0600 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: At 16:29 08/06/2008, Lew L wrote: >As a matter of interest is the Sun Comm API documentation available >somewhere? I have tried the Sun site but it seems to have been removed. It's in the file we have posted, link in prev email (sorry, in a huge hurry right now). Javadocs definitely there. >Unless I have missed the documentation for RXTX? I javadocced the RXTX >source but information (to me) is minimal. >Somewhere I got the impression that the Sun Comm API docs is, or was, >compatible with RXTX, what is the best docs to use in conjuntion with RXTX >and where may the be available? Yeah, this is one of my concerns/beefs. There is little documentation for RXTX and it isn't just the same as javaxcomm. I would be willing to help out writing docs for RXTX! Yes really... esp if we can fix the Bluetooth issues. best regards Bruce >Cheers >Lew > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx ------- WWW.SYSTRONIX.COM ---------- Real embedded Java and much more +1-801-534-1017 Salt Lake City, USA From rick_knight at rlknight.com Wed Aug 6 17:54:08 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:54:08 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A39A0.2090309@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff, I would like for my vendor to switch to rxtx 2.1. It would make things much easier for me. I'm not sure why he's still using the javax compatible code. He's a small operation. Re-writing the code to use gnu namespace sounds like a major overhaul. Was it? Thanks, Rick From tjarvi at qbang.org Wed Aug 6 21:35:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:35:12 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: >> >>> Jeff wrote: >>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>>> >>>> >>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things > much easier for me. I'm not sure why he's still using the javax > compatible code. He's a small operation. Re-writing the code to use gnu > namespace sounds like a major overhaul. Was it? > Hi Jeff, The changes are fairly mechanical. Imports need to change and any explicite use of the namespace needs to change such as catching an exception. The following script was made for maintaining rxtx 2.0 but can apply to other needs. It is in the contrib dir with rxtx source. #!/bin/sh # Don't use! :) # # Sat, 03 May 2003 16:45:08 Modifications from J?rg Weule # Create a ed-cmd for the change of one pattern # case $1 in gnu) X=g/javax_comm/s+javax_comm+gnu_io+g ;; javax) X=g/gnu_io/s+gnu_io+javax_comm+g ;; *) echo;echo;echo From the top rxtx directory run;echo;echo -e \\t./ChangePackage.sh gnu;echo -e \\t\\tor;echo -e \\t./ChangePackage.sh javax;echo;echo; exit 0 ;; esac # # ed will be used to keep the owner and mode of the files unchanged. # We have run the ed-script for the characters '.' '/' as well. # "tr _ $D" do the change. # find . -type f -a -print | grep -v $0 | (while read F ; do ( echo $X; echo $X| tr _ /; echo $X| tr _ .; echo w; echo q ) | ed $F 2>&1 >/dev/null done ) # # Now we do little changes at the Makefiles. Hope that all we need. # find . -name Makefile\* -a -print | (while read F ; do cat < References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: On Thu, 7 Aug 2008, Lew L wrote: > As a matter of interest is the Sun Comm API documentation available > somewhere? I have tried the Sun site but it seems to have been removed. > > Unless I have missed the documentation for RXTX? I javadocced the RXTX > source but information (to me) is minimal. > Somewhere I got the impression that the Sun Comm API docs is, or was, > compatible with RXTX, what is the best docs to use in conjuntion with RXTX > and where may the be available? > Hi Lew, The documentation on Sun's website is accurate. The changes that are problematic in 3.0 are on the backside which rxtx used to plug into. http://java.sun.com/products/javacomm/reference/api/index.html CommPortIdentifier may have some minor differences (judging by the authors notes). -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Aug 6 21:46:08 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:46:08 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > If javax.comm.properties is properly installed and you are using a 2.0 version of Sun's commapi with rxtx 2.0, you should not see the library attempt to load libSolarisSerialParallel.so. Sun CommAPI 3.0 will not work with any version of rxtx as it is hard coded to use the shared library. See the INSTALL file with rxtx-2.0 source for more help with the properties file. -- Trent Jarvi tjarvi at qbang.org From jlar310 at gmail.com Thu Aug 7 06:32:06 2008 From: jlar310 at gmail.com (Jeff) Date: Thu, 7 Aug 2008 07:32:06 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > Jeff wrote: >> >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >> wrote: >> >>> >>> Jeff wrote: >>> >>>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>> wrote: >>>> >>>> >>>> >>>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things much > easier for me. I'm not sure why he's still using the javax compatible code. > He's a small operation. Re-writing the code to use gnu namespace sounds like > a major overhaul. Was it? I found it quite easy. In fact, in order to accommodate the transition, I actually separated all of the code that deals directly with the Comm API or RXTX into a helper class. The helper class was then coded to use reflection to determine which library was available and then instantiate the necessary objects. No direct imports of either library are used. The main application just needs to get it's hands on the IO streams and need not deal directly with the libraries. Other programs may not be so simple... But this doesn't really help you unless your vendor forks over the source code... -- Jeff From rick_knight at rlknight.com Thu Aug 7 09:47:12 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Thu, 07 Aug 2008 08:47:12 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: <489B1900.10108@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >>> wrote: >>> >>> >>>> Jeff wrote: >>>> >>>> >>>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>>> copy of the comm.api and I've copied the library >>>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>>> into the proper places. When I try to run the application, I get this >>>>>> error... >>>>>> >>>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>>> /usr/lib/libSolarisSerialParallel.so: >>>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>>> little-endian (Possible cause: endianness mismatch) >>>>>> Caught java.lang.UnsatisfiedLinkError: >>>>>> >>>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>>> >>>>>> while loading driver com.sun.comm.SolarisDriver >>>>>> >>>>>> Is there a way around this error? >>>>>> >>>>>> >>>>>> >>>>> What host OS are you running? From your original post it looks like 32 >>>>> bit Linux. >>>>> >>>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>>> depending on the underlying hardware architecture as well. >>>>> >>>>> >>>>> >>>>> >>>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>>> >>>> >>>> >>> I don't think Sun did binary libraries for Linux in the 2.0 version. >>> Can someone with more historical experience than I confirm that? >>> >>> I recently tried to port a Comm API application from Solaris sparc to >>> Linux x86 and likewise could not get my hands on the binary libraries. >>> I eventually just re-wrote the code to use the gnu namespace packages >>> and rxtx 2.1. >>> >>> What I don't understand is why your application vendor does not >>> provide everything you need to run their software. >>> >>> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >>> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >>> /usr/java/default which is actually a softlink to >>> /usr/java/jre1.6.0_05. >>> >>> >>> >> Jeff, >> >> I would like for my vendor to switch to rxtx 2.1. It would make things much >> easier for me. I'm not sure why he's still using the javax compatible code. >> He's a small operation. Re-writing the code to use gnu namespace sounds like >> a major overhaul. Was it? >> > > I found it quite easy. In fact, in order to accommodate the > transition, I actually separated all of the code that deals directly > with the Comm API or RXTX into a helper class. The helper class was > then coded to use reflection to determine which library was available > and then instantiate the necessary objects. No direct imports of > either library are used. The main application just needs to get it's > hands on the IO streams and need not deal directly with the libraries. > Other programs may not be so simple... > > But this doesn't really help you unless your vendor forks over the > source code... > > Jeff, This may not help me directly, but I'm going to forward this thread to the vendor. I think he'll be open to making things work. Thanks again, Rick Knight From agusmunioz at gmail.com Thu Aug 7 16:39:51 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Thu, 7 Aug 2008 19:39:51 -0300 Subject: [Rxtx] How to send ack? Message-ID: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Hi, I'm still learning about serial communication and I have some doubts. I've got this question about how to do the following thing in rxtx. I have this hardware that connect to a PC using a serial port. These hardware receives data from a telephone line, proccess it, and then send it forward to the serial port. I've used a program named wincomm that shows what information is send it through the serial port and I have the nex behaviour: The hardware has a buffer where all data is stored, that cannot be sent it through the seria port. The program reads the first data send it by the hardware, and keep reading the same data always. There is a button in the application that says enable Ack, and when I click, then the hardware start to send all the stored information, and all the information is shown. I write a class, using rxtx that reads the serial port, and the same thing happens, it remains reading the same (first) data all the time. And I thing something like the enable Ack I'm missing. How can I do this enable Ack from my java code using rxtx? Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080807/e0a0f9a1/attachment-0042.html From ajmas at sympatico.ca Thu Aug 7 18:26:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 7 Aug 2008 20:26:41 -0400 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: <4BF42297-81E2-4BB8-A89F-1D43588379AE@sympatico.ca> On 6-Aug-08, at 19:40 , Bruce Boyes wrote: >> Unless I have missed the documentation for RXTX? I javadocced the >> RXTX >> source but information (to me) is minimal. >> Somewhere I got the impression that the Sun Comm API docs is, or was, >> compatible with RXTX, what is the best docs to use in conjuntion >> with RXTX >> and where may the be available? > > Yeah, this is one of my concerns/beefs. There is little documentation > for RXTX and it isn't just the same as javaxcomm. > > I would be willing to help out writing docs for RXTX! Yes really... > esp if we can fix the Bluetooth issues. If you want to contribute documentation then the best place to do that is the wiki. If there is anything missing or that could be improved on then please do so. If there are any points that you would like to see improved, for which you don't have the knowledge then ask on the mailing list for a volunteer. Andre From florianmanschwetus at gmx.de Fri Aug 8 03:04:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Fri, 08 Aug 2008 11:04:14 +0200 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Message-ID: <489C0C0E.2020401@gmx.de> Agustin Mu?oz schrieb: > Hi, I'm still learning about serial communication and I have some > doubts. I've got this question about how to do the following thing in rxtx. > I have this hardware that connect to a PC using a serial port. These > hardware receives data from a telephone line, proccess it, and then send > it forward to the serial port. I've used a program named wincomm that > shows what information is send it through the serial port and I have the > nex behaviour: > > The hardware has a buffer where all data is stored, that cannot be sent > it through the seria port. > The program reads the first data send it by the hardware, and keep > reading the same data always. > There is a button in the application that says enable Ack, and when I > click, then the hardware start to send all the stored information, and > all the information is shown. > > I write a class, using rxtx that reads the serial port, and the same > thing happens, it remains reading the same (first) data all the time. > And I thing something like the enable Ack I'm missing. > How can I do this enable Ack from my java code using rxtx? Afaik, a look at man ascii reveals: Okt Dez Hex Char 006 6 06 ACK So, i hope this will do the job: send(6); florian > > Thanks in advance > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/5b4965f8/attachment-0042.bin From agusmunioz at gmail.com Fri Aug 8 16:31:00 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 19:31:00 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <489C0C0E.2020401@gmx.de> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> Message-ID: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Hi Florian, thanks for the answer. By send(6) you mean to get the port OutputStream and write a 6? I try that but it didn't work. Any suggestion? Thanks On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < florianmanschwetus at gmx.de> wrote: > Agustin Mu?oz schrieb: > > Hi, I'm still learning about serial communication and I have some doubts. >> I've got this question about how to do the following thing in rxtx. >> I have this hardware that connect to a PC using a serial port. These >> hardware receives data from a telephone line, proccess it, and then send it >> forward to the serial port. I've used a program named wincomm that shows >> what information is send it through the serial port and I have the nex >> behaviour: >> >> The hardware has a buffer where all data is stored, that cannot be sent >> it through the seria port. >> The program reads the first data send it by the hardware, and keep reading >> the same data always. >> There is a button in the application that says enable Ack, and when I >> click, then the hardware start to send all the stored information, and all >> the information is shown. >> >> I write a class, using rxtx that reads the serial port, and the same thing >> happens, it remains reading the same (first) data all the time. And I thing >> something like the enable Ack I'm missing. >> How can I do this enable Ack from my java code using rxtx? >> > Afaik, a look at man ascii reveals: > Okt Dez Hex Char > 006 6 06 ACK > So, i hope this will do the job: > send(6); > > florian > >> >> Thanks in advance >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/7f3fba42/attachment-0041.html From agusmunioz at gmail.com Fri Aug 8 18:39:27 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 21:39:27 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Message-ID: <988288430808081739x7f9e7889id82591d5a9e2b4f6@mail.gmail.com> Ok, Florian, it works!! my problem was that I've been sending, through the OutputStream, the bytes of 6 as a string: out.write("6".getBytes()); but then I realized that you can write an int on an OuptuStream, so I tried that and It works: out.write(6); Thank you for the guidance!! On Fri, Aug 8, 2008 at 7:31 PM, Agustin Mu?oz wrote: > Hi Florian, thanks for the answer. By send(6) you mean to get the port > OutputStream and write a 6? > > I try that but it didn't work. > > Any suggestion? > > Thanks > > > On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < > florianmanschwetus at gmx.de> wrote: > >> Agustin Mu?oz schrieb: >> >> Hi, I'm still learning about serial communication and I have some doubts. >>> I've got this question about how to do the following thing in rxtx. >>> I have this hardware that connect to a PC using a serial port. These >>> hardware receives data from a telephone line, proccess it, and then send it >>> forward to the serial port. I've used a program named wincomm that shows >>> what information is send it through the serial port and I have the nex >>> behaviour: >>> >>> The hardware has a buffer where all data is stored, that cannot be sent >>> it through the seria port. >>> The program reads the first data send it by the hardware, and keep >>> reading the same data always. >>> There is a button in the application that says enable Ack, and when I >>> click, then the hardware start to send all the stored information, and all >>> the information is shown. >>> >>> I write a class, using rxtx that reads the serial port, and the same >>> thing happens, it remains reading the same (first) data all the time. And I >>> thing something like the enable Ack I'm missing. >>> How can I do this enable Ack from my java code using rxtx? >>> >> Afaik, a look at man ascii reveals: >> Okt Dez Hex Char >> 006 6 06 ACK >> So, i hope this will do the job: >> send(6); >> >> florian >> >>> >>> Thanks in advance >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/b918ab3d/attachment-0041.html From florianmanschwetus at gmx.de Sat Aug 9 00:45:43 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Sat, 09 Aug 2008 08:45:43 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4899667C.6010706@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> Message-ID: <489D3D17.9090209@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >> Florian Manschwetus wrote: >>> Ok, sounds fine for the receiving problem. >>> But why i have to wait after each byte when sending a command squence? >>> (the for loop in send command) >> >> Hi Florian, >> I'd imagine you probably don't! You could send all bytes in one go and >> RXTX would send them. The problem is most probably the other end: >> perhaps it has a really small buffer, some non-standard UART, or a >> crazy timing issue. If you attach a terminal to your output and send >> all the bytes of a command in one go they should appear no problem. >> >> Regards, >> Michael Erskine. >> > correct with a terminal on the other end it works, my idea was that this > basic baud has some influence. Could some one explain what it is for? > > Florian To make it more clear, my problem is that i can't use: outputStream.write(byte[]); => Beamer doesn't understand the sequence. (mostly no answer when he answers then *001) when i use this construct instead: for (int i = 0; i < command.length; i++) { this.outputStream.write(command[i]); try { Thread.sleep(25); } catch (InterruptedException e) { // TODO Auto-generated catch block e.printStackTrace(); } } it works nearly reliable. So what could it be? This Basic Baud is what exactly? Florian -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080809/692304ee/attachment-0041.bin From tjarvi at qbang.org Sat Aug 9 16:37:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Aug 2008 16:37:19 -0600 (MDT) Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489D3D17.9090209@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> <489D3D17.9090209@gmx.de> Message-ID: On Sat, 9 Aug 2008, Florian Manschwetus wrote: > Florian Manschwetus schrieb: >> Michael Erskine schrieb: >>> Florian Manschwetus wrote: >>>> Ok, sounds fine for the receiving problem. >>>> But why i have to wait after each byte when sending a command squence? >>>> (the for loop in send command) >>> >>> Hi Florian, >>> I'd imagine you probably don't! You could send all bytes in one go and >>> RXTX would send them. The problem is most probably the other end: perhaps >>> it has a really small buffer, some non-standard UART, or a crazy timing >>> issue. If you attach a terminal to your output and send all the bytes of a >>> command in one go they should appear no problem. >>> >>> Regards, >>> Michael Erskine. >>> >> correct with a terminal on the other end it works, my idea was that this >> basic baud has some influence. Could some one explain what it is for? >> >> Florian > To make it more clear, > my problem is that i can't use: > outputStream.write(byte[]); > => Beamer doesn't understand the sequence. (mostly no answer when he answers > then *001) > > when i use this construct instead: > > for (int i = 0; i < command.length; i++) { > this.outputStream.write(command[i]); > try { > Thread.sleep(25); > } catch (InterruptedException e) { > // TODO Auto-generated catch block > e.printStackTrace(); > } > } > > it works nearly reliable. > > So what could it be? This Basic Baud is what exactly? > I suspect you are using the 'moon protocol' and don't know it. RXTX enables this by default. The buffer on the other end is first in first out while reading. If the buffer is full, the bits are hand carried to the moon and burried. Then if the other side reads a couple bytes, two more bytes go into the buffer followed by more moon protocol. The resulting array of bytes the other side reads may appear to be scrambled until you go to the moon, get the bits and insert them in the right place. Flow control can prevent the default moon protocol and throttles the communiation by almost writing a byte at a time as need be. Hardware flow control is preferable but software flow control should also work. Read and write can appear to hang if the other side is not connected. This is why we don't enable them all the time. If you can't use flow control, you have to take care with the moon protocol and give the other side time to read. That is what your slower version of write is doing. -- Trent Jarvi tjarvi at qbang.org From rxtx at allenjb.me.uk Mon Aug 11 08:06:36 2008 From: rxtx at allenjb.me.uk (AllenJB) Date: Mon, 11 Aug 2008 15:06:36 +0100 Subject: [Rxtx] Disabling EV_RXFLAG Message-ID: <48A0476C.2090800@allenjb.me.uk> Hi all, I'm working with a device which does not use an EvtChar and need to disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an event mask of FD 01 00 00. The reference software I have uses FB 00 00 00. With the rxtx mask I get framing errors which I believe are caused when the EvtChar is received. Is there currently a way with rxtx (I've using rxtx from Java) to disable EV_RXFLAG? If not from Java, where would I start if I wanted to turn the EV_RXFLAG option off in the C code? I've had a grep of the rxtx source code, but I can't see where EV_RXFLAG is being set. Thanks in advance, AllenJB From tjarvi at qbang.org Mon Aug 11 14:17:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Aug 2008 14:17:27 -0600 (MDT) Subject: [Rxtx] Disabling EV_RXFLAG In-Reply-To: <48A0476C.2090800@allenjb.me.uk> References: <48A0476C.2090800@allenjb.me.uk> Message-ID: On Mon, 11 Aug 2008, AllenJB wrote: > Hi all, > > I'm working with a device which does not use an EvtChar and need to > disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an > event mask of FD 01 00 00. The reference software I have uses FB 00 00 > 00. With the rxtx mask I get framing errors which I believe are caused > when the EvtChar is received. > > Is there currently a way with rxtx (I've using rxtx from Java) to > disable EV_RXFLAG? > > If not from Java, where would I start if I wanted to turn the EV_RXFLAG > option off in the C code? I've had a grep of the rxtx source code, but I > can't see where EV_RXFLAG is being set. > > Thanks in advance, > > AllenJB Hi Allen, I'd look at termios.c::tcsetattr() and termios.c::FillDCB() -- Trent Jarvi tjarvi at qbang.org From superdadusa at gmail.com Tue Aug 12 13:57:32 2008 From: superdadusa at gmail.com (John Choi) Date: Tue, 12 Aug 2008 13:57:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. Message-ID: Hi all, Just let you all know I just start to learn Java. I have download the serial comm package and the source code from open source communities.. I was able to verify with the given message string via serial monitor. when the given message string sends to the serial port then the character return added to the end of string by default if I use "Hello World" however if I changed to something else other than "Hello, World" there is no character return add to the end of string. I thing the library download from rxtx.org has implemented for the special strings. I can do like "login\n" in the string message to make character return but I don't want to add this individual custom character for each command return in every static message string I send, Can any who have done this might help me? Basically, something like this,, Write and add function to the program write a command, Reads the respond from a serial device.. Function handles multiple messages, Write: "com open" Read: Welcome to my world" expected Write: "admin" Read: Password?, expected Write: "admin" Read: you are successfully login terminal, expected. And I need to add a separate function handler handles a character return add to the each command above. If anyone can help this I can do the reset? Thank you in advance, John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0037.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SerialIO.java Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0037.pl From Steffen.DETTMER at ingenico.com Wed Aug 13 02:16:38 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 13 Aug 2008 10:16:38 +0200 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: References: Message-ID: <20080813081638.GA25412@elberon.bln.de.ingenico.com> * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > I can do like "login\n" in the string message to make character > return but I don't want to add this individual custom character > for each command return in every static message string I send, and why not?! > Can any who have done this might help me? what's about with writing a small wrapper function adding the carriage return? However, this would be slow, because either you call write two times (very bad) or the string needs to be copied, \n appended and written (since you are using Java Performance probably isn't so critical). Personally I would write `"login\n"' and `username + "\n"' etc., because since it is part of the command it should be part of the command definition string. > Basically, something like this,, Write and add function to the program write > a command, Reads the respond from a serial device.. correctly reading a `line' is more difficult. If you cannot make assumptions about timeouts and/or you need to have low delay, you need to read byte wise. If you need to save CPU resources you might need to add some buffering layer that you can read byte-wise but that is reading blockwise with some small timeout (lets say for serial lines something around byte transmission time times three or so). > /* > * To change this template, choose Tools | Templates > * and open the template in the editor. > */ :) > package joliba; > > /** > * > * @author root > */ :) > // derived from SUN's examples in the javax.comm package > import java.io.*; > import java.util.*; > //import javax.comm.*; // for SUN's serial/parallel port libraries > import gnu.io.*; // for rxtxSerial library > > public class SerialIO implements Runnable, SerialPortEventListener { > static CommPortIdentifier portId; > static CommPortIdentifier saveportId; > static Enumeration portList; > InputStream inputStream; > SerialPort serialPort; > Thread readThread; You need a thread for your synchronous RPC-style protocol? > static String messageString = "Hello, world!"; > static OutputStream outputStream; > static boolean outputBufferEmptyFlag = false; > > public static void main(String[] args) { > boolean portFound = false; > String defaultPort; > > // determine the name of the serial port on several operating systems > String osname = System.getProperty("os.name","").toLowerCase(); > if ( osname.startsWith("windows") ) { > // windows > defaultPort = "COM1"; > } else if (osname.startsWith("linux")) { > // linux > defaultPort = "/dev/ttyS0"; > } else if ( osname.startsWith("mac") ) { > // mac > defaultPort = "????"; > } else { > System.out.println("Sorry, your operating system is not supported"); > return; > } Is such a construction recommended? Isn't there some abstraction (like COM1 working on any platform)? [...] > try { > // activate the OUTPUT_BUFFER_EMPTY notifier > serialPort.notifyOnOutputEmpty(true); > } catch (Exception e) { > System.out.println("Error setting event notification"); > System.out.println(e.toString()); > System.exit(-1); > } I doubt that -1 is defined, probably some 127 or so would be the result, maybe better simply `throw e'? > public void writetoport() { > System.out.println("Writing \""+messageString+"\" to "+serialPort.getName()); > try { > // write string to serial port > outputStream.write(messageString.getBytes()); > } catch (IOException e) {} > } maybe something like /** * Writes the given output string and an additional carriage * return to the current outputStream. */ public void writeStringToPort( /** The output string (without CR). */ String output ) throws IOException { String outputLine = output + "\n"; outputStream.write(outputLine.getBytes()); } ? > > public SerialIO() { > // initalize serial port > try { > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > } catch (PortInUseException e) {} if the port is in use, you continue? Wonder that this works in Java, I would assume serialPort beeing uninitialized which AFAIK is an error in Java. > try { > inputStream = serialPort.getInputStream(); > } catch (IOException e) {} > > try { > serialPort.addEventListener(this); > } catch (TooManyListenersException e) {} > > // activate the DATA_AVAILABLE notifier > serialPort.notifyOnDataAvailable(true); > > try { > // set port parameters > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > } catch (UnsupportedCommOperationException e) {} > > // start the read thread > readThread = new Thread(this); > readThread.start(); > > } I think in all those exception cases you can abort, because it is unlikely that ignoring those errors allow a successful continuation, so in this case maybe it would be better to add a throw clause to the method. > public void run() { > // first thing in the thread, we initialize the write operation > initwritetoport(); > try { > while (true) { > // write string to port, the serialEvent will read it > writetoport(); > Thread.sleep(1000); > } > } catch (InterruptedException e) {} > } Does this make sense? Your `SimpleReadApp' writes one and the same string each second? > public void serialEvent(SerialPortEvent event) { > switch (event.getEventType()) { > case SerialPortEvent.BI: > case SerialPortEvent.OE: > case SerialPortEvent.FE: > case SerialPortEvent.PE: > case SerialPortEvent.CD: > case SerialPortEvent.CTS: > case SerialPortEvent.DSR: > case SerialPortEvent.RI: > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > break; > case SerialPortEvent.DATA_AVAILABLE: > // we get here if data has been received > byte[] readBuffer = new byte[20]; > try { > // read data > while (inputStream.available() > 0) { > int numBytes = inputStream.read(readBuffer); > } > // print data > String result = new String(readBuffer); > System.out.println("Read: "+result); > } catch (IOException e) {} I doubt that this is correct. I would assume you will get a 20 bytes result always, if more bytes would be available they would be printed in a second line but if less bytes are read I'd assume that the buffer/result contains zero bytes from implicite readBuffer contents initialisation (zero is no string terminator in Java AFAIK). > break; > } > } > } oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From florianmanschwetus at gmx.de Wed Aug 13 06:09:31 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 13 Aug 2008 14:09:31 +0200 Subject: [Rxtx] someone has seen such errors? Message-ID: <48A2CEFB.90007@gmx.de> I mean my communication mostly works, but it is far from perfect could this be the reason? Florian Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/949b9947/attachment-0037.bin From superdadusa at gmail.com Wed Aug 13 08:40:32 2008 From: superdadusa at gmail.com (John Choi) Date: Wed, 13 Aug 2008 08:40:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: <20080813081638.GA25412@elberon.bln.de.ingenico.com> References: <20080813081638.GA25412@elberon.bln.de.ingenico.com> Message-ID: Thank you so much Steffen and I will try that suggestion. John On 8/13/08, Steffen DETTMER wrote: > > * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > > I can do like "login\n" in the string message to make character > > return but I don't want to add this individual custom character > > for each command return in every static message string I send, > > and why not?! > > > Can any who have done this might help me? > > what's about with writing a small wrapper function adding the > carriage return? > However, this would be slow, because either you call write two > times (very bad) or the string needs to be copied, \n appended > and written (since you are using Java Performance probably isn't > so critical). > > Personally I would write `"login\n"' and `username + "\n"' etc., > because since it is part of the command it should be part of the > command definition string. > > > Basically, something like this,, Write and add function to the program > write > > a command, Reads the respond from a serial device.. > > correctly reading a `line' is more difficult. If you cannot make > assumptions about timeouts and/or you need to have low delay, you > need to read byte wise. If you need to save CPU resources you > might need to add some buffering layer that you can read > byte-wise but that is reading blockwise with some small timeout > (lets say for serial lines something around byte transmission > time times three or so). > > > /* > > * To change this template, choose Tools | Templates > > * and open the template in the editor. > > */ > > :) > > > package joliba; > > > > /** > > * > > * @author root > > */ > > :) > > > // derived from SUN's examples in the javax.comm package > > import java.io.*; > > import java.util.*; > > //import javax.comm.*; // for SUN's serial/parallel port libraries > > import gnu.io.*; // for rxtxSerial library > > > > public class SerialIO implements Runnable, SerialPortEventListener { > > static CommPortIdentifier portId; > > static CommPortIdentifier saveportId; > > static Enumeration portList; > > InputStream inputStream; > > SerialPort serialPort; > > Thread readThread; > > You need a thread for your synchronous RPC-style protocol? > > > static String messageString = "Hello, world!"; > > static OutputStream outputStream; > > static boolean outputBufferEmptyFlag = false; > > > > public static void main(String[] args) { > > boolean portFound = false; > > String defaultPort; > > > > // determine the name of the serial port on several operating > systems > > String osname = System.getProperty("os.name","").toLowerCase(); > > if ( osname.startsWith("windows") ) { > > // windows > > defaultPort = "COM1"; > > } else if (osname.startsWith("linux")) { > > // linux > > defaultPort = "/dev/ttyS0"; > > } else if ( osname.startsWith("mac") ) { > > // mac > > defaultPort = "????"; > > } else { > > System.out.println("Sorry, your operating system is not > supported"); > > return; > > } > > Is such a construction recommended? Isn't there some abstraction > (like COM1 working on any platform)? > > [...] > > try { > > // activate the OUTPUT_BUFFER_EMPTY notifier > > serialPort.notifyOnOutputEmpty(true); > > } catch (Exception e) { > > System.out.println("Error setting event notification"); > > System.out.println(e.toString()); > > System.exit(-1); > > } > > I doubt that -1 is defined, probably some 127 or so would be the > result, maybe better simply `throw e'? > > > public void writetoport() { > > System.out.println("Writing \""+messageString+"\" to > "+serialPort.getName()); > > try { > > // write string to serial port > > outputStream.write(messageString.getBytes()); > > } catch (IOException e) {} > > } > > maybe something like > > /** > * Writes the given output string and an additional carriage > * return to the current outputStream. > */ > public void > writeStringToPort( > /** The output string (without CR). */ > String output > ) throws IOException > { > String outputLine = output + "\n"; > outputStream.write(outputLine.getBytes()); > } > > ? > > > > > public SerialIO() { > > // initalize serial port > > try { > > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > > } catch (PortInUseException e) {} > > if the port is in use, you continue? Wonder that this works in > Java, I would assume serialPort beeing uninitialized which AFAIK > is an error in Java. > > > try { > > inputStream = serialPort.getInputStream(); > > } catch (IOException e) {} > > > > try { > > serialPort.addEventListener(this); > > } catch (TooManyListenersException e) {} > > > > // activate the DATA_AVAILABLE notifier > > serialPort.notifyOnDataAvailable(true); > > > > try { > > // set port parameters > > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > } catch (UnsupportedCommOperationException e) {} > > > > // start the read thread > > readThread = new Thread(this); > > readThread.start(); > > > > } > > I think in all those exception cases you can abort, because it is > unlikely that ignoring those errors allow a successful > continuation, so in this case maybe it would be better to add a > throw clause to the method. > > > public void run() { > > // first thing in the thread, we initialize the write operation > > initwritetoport(); > > try { > > while (true) { > > // write string to port, the serialEvent will read it > > writetoport(); > > Thread.sleep(1000); > > } > > } catch (InterruptedException e) {} > > } > > Does this make sense? Your `SimpleReadApp' writes one and the > same string each second? > > > public void serialEvent(SerialPortEvent event) { > > switch (event.getEventType()) { > > case SerialPortEvent.BI: > > case SerialPortEvent.OE: > > case SerialPortEvent.FE: > > case SerialPortEvent.PE: > > case SerialPortEvent.CD: > > case SerialPortEvent.CTS: > > case SerialPortEvent.DSR: > > case SerialPortEvent.RI: > > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > > break; > > case SerialPortEvent.DATA_AVAILABLE: > > // we get here if data has been received > > byte[] readBuffer = new byte[20]; > > try { > > // read data > > while (inputStream.available() > 0) { > > int numBytes = inputStream.read(readBuffer); > > } > > // print data > > String result = new String(readBuffer); > > System.out.println("Read: "+result); > > } catch (IOException e) {} > > I doubt that this is correct. I would assume you will get a 20 > bytes result always, if more bytes would be available they would > be printed in a second line but if less bytes are read I'd assume > that the buffer/result contains zero bytes from implicite > readBuffer contents initialisation (zero is no string terminator > in Java AFAIK). > > > break; > > } > > } > > } > > oki, > > Steffen > > About Ingenico Throughout the world businesses rely on Ingenico for secure > and expedient electronic transaction acceptance. Ingenico products leverage > proven technology, established standards and unparalleled ergonomics to > provide optimal reliability, versatility and usability. This comprehensive > range of products is complemented by a global array of services and > partnerships, enabling businesses in a number of vertical sectors to accept > transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged > information. If you are not the addressee or authorized to receive this for > the addressee, you must not use, copy, disclose or take any action based on > this message or any information herein. If you have received this message in > error, please advise the sender immediately by reply e-mail and delete this > message. Thank you for your cooperation. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/73c4135c/attachment-0036.html From ajmas at sympatico.ca Sat Aug 16 07:15:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 09:15:41 -0400 Subject: [Rxtx] someone has seen such errors? In-Reply-To: <48A2CEFB.90007@gmx.de> References: <48A2CEFB.90007@gmx.de> Message-ID: <43B5E8DA-1D93-4D90-809B-AAF35FF724C5@sympatico.ca> On 13-Aug-08, at 08:09 , Florian Manschwetus wrote: > I mean my communication mostly works, but it is far from perfect > could this be the reason? > > Florian > > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control Judging by the error messages this looks related to the driver you are using. Do a search for the following string with you favourite search engine, it should turn up a few hits: ftdi_set_termios FAILED to set databits/stopbits/parity Andre From ajmas at sympatico.ca Sat Aug 16 19:12:04 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 21:12:04 -0400 Subject: [Rxtx] Using SerialPortEvent? Message-ID: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Hi, Could someone tell me how I should be using the SerialPortEvent? Am I meant to be waiting for data and then simply reading from the inputstream? If this is the case why no just block on an inputstream read? Andr? From tjarvi at qbang.org Sat Aug 16 19:41:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 16 Aug 2008 19:41:13 -0600 (MDT) Subject: [Rxtx] Using SerialPortEvent? In-Reply-To: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> References: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Message-ID: On Sat, 16 Aug 2008, Andre-John Mas wrote: > Hi, > > Could someone tell me how I should be using the SerialPortEvent? Am I > meant to be waiting for data and then simply reading from the > inputstream? If this is the case why no just block on an inputstream > read? > Polling for data is fine also. It really depends upon what you are trying to do. For instance, if you require x bytes before reading, you can start polling after data is available. If you read on the same thread as your GUI and are waiting for data in a read, the results may be less than desirable. Java programming is 'usually' event driven rather than polling based. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sat Aug 16 20:10:39 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 22:10:39 -0400 Subject: [Rxtx] Using SerialPortEvent? In-Reply-To: References: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Message-ID: <3E495D4C-BB28-4845-A6AB-984C9A826BDF@sympatico.ca> On 16-Aug-08, at 21:41 , Trent Jarvi wrote: > On Sat, 16 Aug 2008, Andre-John Mas wrote: > >> Hi, >> >> Could someone tell me how I should be using the SerialPortEvent? Am I >> meant to be waiting for data and then simply reading from the >> inputstream? If this is the case why no just block on an inputstream >> read? >> > > Polling for data is fine also. It really depends upon what you are > trying to do. For instance, if you require x bytes before reading, > you can start polling after data is available. If you read on the > same thread as your GUI and are waiting for data in a read, the > results may be less than desirable. > > Java programming is 'usually' event driven rather than polling based. Sounds good. I thought I would use this opportunity to provide a event based version of the TwoWaySerialComm example. Could you just validate it before I add it to the Wiki: package ajmas74.experimental; import gnu.io.CommPort; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; import gnu.io.SerialPortEvent; import gnu.io.SerialPortEventListener; import java.io.IOException; import java.io.InputStream; import java.io.OutputStream; /** * This version of the TwoWaySerialComm example makes use of the * SerialPortEventListener to avoid polling. * * @author ajmas * */ public class TwoWaySerialComm { public TwoWaySerialComm() { super(); } void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { CommPort commPort = portIdentifier.open(this.getClass().getName(),2000); if ( commPort instanceof SerialPort ) { SerialPort serialPort = (SerialPort) commPort; serialPort .setSerialPortParams (57600 ,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); (new Thread(new SerialWriter(out))).start(); serialPort.addEventListener(new SerialReader(in)); } else { System.out.println("Error: Only serial ports are handled by this example."); } } } /** * Handles the input coming from the serial port. A new line character * is treated as the end of a block in this example. */ public static class SerialReader implements SerialPortEventListener { private InputStream in; private byte[] buffer = new byte[1024]; public SerialReader ( InputStream in ) { this.in = in; } public void serialEvent(SerialPortEvent arg0) { int data; try { int len = 0; while ( ( data = in.read()) > -1 ) { if ( data != '\n' ) { break; } buffer[len++] = (byte) data; } System.out.print(new String(buffer,0,len)); } catch ( IOException e ) { e.printStackTrace(); System.exit(-1); } } } /** */ public static class SerialWriter implements Runnable { OutputStream out; public SerialWriter ( OutputStream out ) { this.out = out; } public void run () { try { int c = 0; while ( ( c = System.in.read()) > -1 ) { this.out.write(c); } } catch ( IOException e ) { e.printStackTrace(); System.exit(-1); } } } public static void main ( String[] args ) { try { (new TwoWaySerialComm()).connect("COM3"); } catch ( Exception e ) { e.printStackTrace(); } } } From lfarkas at lfarkas.org Tue Aug 19 07:32:59 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Tue, 19 Aug 2008 15:32:59 +0200 Subject: [Rxtx] JNI or CNI Message-ID: <48AACB8B.9060606@lfarkas.org> hi, what is the current recommended way to rxtx on linux JNI or it's better to use CNI? is the CNI version fully functional and the same level as the JNI? i currently try to make a rhel/centos/fedora rpm for rxtx but has many problems with the standard dir structure. yours. -- Levente "Si vis pacem para bellum!" From lfarkas at lfarkas.org Tue Aug 19 08:47:34 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Tue, 19 Aug 2008 16:47:34 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel Message-ID: <48AADD06.7040809@lfarkas.org> hi, newer or not so newer linux kernel do not contain the UTS_RELEASE so the current rxtx is not compile on the latest kernels. even if it's commented out in the cvs configure there are other places. i attcahed a patch which fix it (or at least doesn't cause error at non-debug build). ps. is there any plan to the new 2.1-8 release in the near future? there are many changes (at least the license change in all file and in this case create a diff is very difficult)? the latest release more then 2 years old:-( -- Levente "Si vis pacem para bellum!" -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-2.1-uts.patch Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080819/ab5d38ac/attachment-0030.pl From ajmas at sympatico.ca Tue Aug 19 16:21:53 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 19 Aug 2008 18:21:53 -0400 Subject: [Rxtx] Event based example Message-ID: <24735BFB-B088-4B84-8173-FE98DF63B12F@sympatico.ca> Hi, I have just posted an example of using SerialPortEventListener in the Wiki: http://rxtx.qbang.org/wiki/index.php/Event_Based_Two_Way_Communication If you see any issues please could you let me know, or makes the changes. Andre From Martin.Oberhuber at windriver.com Fri Aug 22 04:02:24 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 22 Aug 2008 12:02:24 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <48AADD06.7040809@lfarkas.org> References: <48AADD06.7040809@lfarkas.org> Message-ID: <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> Farkas, there are indeed efforts to get a new RXTX release out the door. Your experience as a package maintainer would likely be helpful during these efforts, since I'd think it makes sense to keep the patches minimal that you must make to have the source compile in your environment. What are the things that you find problematic, apart from the UTS thing that you have mentioned before? What is the timing that you have in mind for your package? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Farkas Levente > Sent: Tuesday, August 19, 2008 4:48 PM > To: rxtx at qbang.org > Subject: [Rxtx] UTS_RELEASE not defined in newer kernel > > hi, > newer or not so newer linux kernel do not contain the > UTS_RELEASE so the > current rxtx is not compile on the latest kernels. even if it's > commented out in the cvs configure there are other places. > i attcahed a patch which fix it (or at least doesn't cause error at > non-debug build). > > ps. is there any plan to the new 2.1-8 release in the near > future? there > are many changes (at least the license change in all file and in this > case create a diff is very difficult)? the latest release more then 2 > years old:-( > > -- > Levente "Si vis pacem para bellum!" > From lfarkas at lfarkas.org Fri Aug 22 04:36:26 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Fri, 22 Aug 2008 12:36:26 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> References: <48AADD06.7040809@lfarkas.org> <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> Message-ID: <48AE96AA.6090505@lfarkas.org> hi, the packages already build for fedora-9 and centos-5 and here: http://www.lfarkas.org/linux/packages/ what i've to patch, the UTS, the configure script, but it's already fixed in the cvs (in another way) and the loadlibrary. the reasons for last one can be found here: https://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_files_that_use_JNI after we test it i'd like to add these packages to fedora and epel main repository (that's why it's be useful a new release after 2 years:-) imho versions are cheap and why not just release 2.1-8? the real code changes are minimal and if something critical bug found still can release 2.1-9:-) ps. and would be better to use simple number for version like 2.1-7 rather then 2.1-7v2. Oberhuber, Martin wrote: > Farkas, > > there are indeed efforts to get a new RXTX release out the > door. Your experience as a package maintainer would likely > be helpful during these efforts, since I'd think it makes > sense to keep the patches minimal that you must make to > have the source compile in your environment. > > What are the things that you find problematic, apart from > the UTS thing that you have mentioned before? > > What is the timing that you have in mind for your package? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >> On Behalf Of Farkas Levente >> Sent: Tuesday, August 19, 2008 4:48 PM >> To: rxtx at qbang.org >> Subject: [Rxtx] UTS_RELEASE not defined in newer kernel >> >> hi, >> newer or not so newer linux kernel do not contain the >> UTS_RELEASE so the >> current rxtx is not compile on the latest kernels. even if it's >> commented out in the cvs configure there are other places. >> i attcahed a patch which fix it (or at least doesn't cause error at >> non-debug build). >> >> ps. is there any plan to the new 2.1-8 release in the near >> future? there >> are many changes (at least the license change in all file and in this >> case create a diff is very difficult)? the latest release more then 2 >> years old:-( >> >> -- >> Levente "Si vis pacem para bellum!" >> -- Levente "Si vis pacem para bellum!" From tjarvi at qbang.org Fri Aug 22 18:50:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Aug 2008 18:50:32 -0600 (MDT) Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <48AE96AA.6090505@lfarkas.org> References: <48AADD06.7040809@lfarkas.org> <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> <48AE96AA.6090505@lfarkas.org> Message-ID: Hi Farkas, The v2 was simply the second build - no code changes. We are comming out with a new release shortly. I would encourage working with distros as you are. The building of rxtx turns out to be a bottle neck in quick releases. We do want stable releases that work for a year or more but I would have no problems with quicker cycles on developing work. I would have no problem working with someone that did builds that receive less testing more often but they do have to come out for multiple platforms from this end. Thanks for the links. On Fri, 22 Aug 2008, Farkas Levente wrote: > hi, > the packages already build for fedora-9 and centos-5 and here: > http://www.lfarkas.org/linux/packages/ > what i've to patch, the UTS, the configure script, but it's already > fixed in the cvs (in another way) and the loadlibrary. the reasons for > last one can be found here: > https://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_files_that_use_JNI > after we test it i'd like to add these packages to fedora and epel main > repository (that's why it's be useful a new release after 2 years:-) > imho versions are cheap and why not just release 2.1-8? the real code > changes are minimal and if something critical bug found still can > release 2.1-9:-) > > ps. and would be better to use simple number for version like 2.1-7 > rather then 2.1-7v2. > > Oberhuber, Martin wrote: >> Farkas, >> >> there are indeed efforts to get a new RXTX release out the >> door. Your experience as a package maintainer would likely >> be helpful during these efforts, since I'd think it makes >> sense to keep the patches minimal that you must make to >> have the source compile in your environment. >> >> What are the things that you find problematic, apart from >> the UTS thing that you have mentioned before? >> >> What is the timing that you have in mind for your package? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >>> On Behalf Of Farkas Levente >>> Sent: Tuesday, August 19, 2008 4:48 PM >>> To: rxtx at qbang.org >>> Subject: [Rxtx] UTS_RELEASE not defined in newer kernel >>> >>> hi, >>> newer or not so newer linux kernel do not contain the >>> UTS_RELEASE so the >>> current rxtx is not compile on the latest kernels. even if it's >>> commented out in the cvs configure there are other places. >>> i attcahed a patch which fix it (or at least doesn't cause error at >>> non-debug build). >>> >>> ps. is there any plan to the new 2.1-8 release in the near >>> future? there >>> are many changes (at least the license change in all file and in this >>> case create a diff is very difficult)? the latest release more then 2 >>> years old:-( >>> >>> -- >>> Levente "Si vis pacem para bellum!" >>> > > > From andy at triera.net Sat Aug 23 15:17:44 2008 From: andy at triera.net (Andy Rozman) Date: Sat, 23 Aug 2008 21:17:44 +0000 Subject: [Rxtx] port not identified on FreeBSD In-Reply-To: References: Message-ID: <48B07E78.2030306@triera.net> Hi ! I have one small problem... I have started using FreeBSD in last few days and I have come accross a problem with rxtx on FreeBSD. I am using usb-to-serial converter, which is identified under FreeBSD without problem as ucom0, and creates link under /dev called ttyU0, which is correct way to be done under FreeBSD (if device would be unidentified it would be called ugen0 - as usb generic). Problem is that I say to rxtx to get my all serial ports this one is not among them. Which names are permissable under linux-like implementations? Which will be accepted as serial ports? Andy From tjarvi at qbang.org Sat Aug 23 13:57:45 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 23 Aug 2008 13:57:45 -0600 (MDT) Subject: [Rxtx] port not identified on FreeBSD In-Reply-To: <48B07E78.2030306@triera.net> References: <48B07E78.2030306@triera.net> Message-ID: On Sat, 23 Aug 2008, Andy Rozman wrote: > Hi ! > > I have one small problem... I have started using FreeBSD in last few > days and I have come accross a problem with rxtx on FreeBSD. > > I am using usb-to-serial converter, which is identified under FreeBSD > without problem as ucom0, and creates link under /dev called > ttyU0, which is correct way to be done under FreeBSD (if device would be > unidentified it would be called ugen0 - as usb generic). Problem is that > I say to rxtx to get my all serial ports this one is not among them. > Which names are permissable under linux-like implementations? Which will > be accepted as serial ports? > > Andy > Thanks Andy! We will add ttyU* to FreeBSD. For now you can use properties to enable the port. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting#How_does_rxtx_detect_ports.3F__Can_I_override_it.3F The fix: diff -u -r1.16.2.59 RXTXCommDriver.java --- RXTXCommDriver.java 18 Nov 2007 22:32:41 -0000 1.16.2.59 +++ RXTXCommDriver.java 23 Aug 2008 19:55:25 -0000 @@ -644,6 +644,7 @@ { String[] Temp = { "ttyd", //general purpose serial ports + "ttyU", //general purpose USB serial ports "cuaa", //dialout serial ports "ttyA", //Specialix SI/XIO dialin ports "cuaA", //Specialix SI/XIO dialout ports -- Trent Jarvi tjarvi at qbang.org From rick_knight at rlknight.com Mon Aug 4 13:25:10 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Mon, 04 Aug 2008 12:25:10 -0700 Subject: [Rxtx] Sun's Comm API? Message-ID: <48975796.4010600@rlknight.com> I have an application that requires the javax compatible version of RXTX and Sun's comm api. I've been able to download and extract the version of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api anywhere. Can someone tell me where I can find it? Or maybe send me a copy? Also, when I try to build RXTX, configure and make complete successfully but make install failes with this error libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 I've never come accross this error before. How can I get past it? Thanks, Rick From bboyes at systronix.com Mon Aug 4 19:10:01 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:10:01 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48975796.4010600@rlknight.com> References: <48975796.4010600@rlknight.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/cb9c6167/attachment-0046.html From bboyes at systronix.com Mon Aug 4 19:12:37 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:12:37 -0600 Subject: [Rxtx] Towards an RXTX release - CSR BT/USB chipset In-Reply-To: <488FB7E7.8000802@gmail.com> References: <460801A4097E3D4CA04CC64EE648584806C56CF0@ism-mail03.corp.ad.wrs.com> <13557-75390@sneakemail.com> <20980-23424@sneakemail.com> <488FB7E7.8000802@gmail.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/52236088/attachment-0046.html From tjarvi at qbang.org Mon Aug 4 19:42:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 19:42:21 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: On Mon, 4 Aug 2008, Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: > I have an application that requires the javax compatible > version of RXTX > and Sun's comm api. I've been able to download and extract > the version > of RXTX that I need (2.0-7pre2) but I can't find Sun's camm > api > anywhere. Can someone tell me where I can find it? Or maybe > send me a > > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm port > support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have just > a ZIP with only the .class JAR file - no source or docs), has a readme > with these comments: > > This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release.? The 2.0.3 release itself is > no longer distributed.? comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project.? The RxTx project (http://www.rxtx.org ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org) was opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support.? Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins.? Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > ? > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > I hope that is helpful! > It would be nice to work with Sun to resolve those longstanding issues. But it may not be practical unless the process goes as fast and painless as the grandfathering of commapi did. Another option may be the old kaffe extensions that moved to gnu classpathx. These don't have the native libraries but should provide the 2.0 interface and the javax.comm.properties mechansim for SPI. http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Mon Aug 4 20:23:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Mon, 04 Aug 2008 20:23:57 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4897B9BD.5070809@ergotech.com> Has there been any work/would it be possible, to layer a javacomm look-alike on top of the GNU code? The goal is not to move the javax code forward, but to emulate the "legacy" javax packages for people who still need this. Jim Trent Jarvi wrote: > On Mon, 4 Aug 2008, Bruce Boyes wrote: > >> At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible >> version of RXTX >> and Sun's comm api. I've been able to download and extract >> the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm >> api >> anywhere. Can someone tell me where I can find it? Or maybe >> send me a >> >> >> javaxcomm has had a sort of on-again off-again history. The windoze >> version has been languishing for years (literally) but there are newer >> versions for other OS's. >> >> We try to keep links on one of our help pages current: >> http://www.practicalembeddedjava.com/tools/javatools_list.html >> which gets you to here: >> http://java.sun.com/products/javacomm/ >> where it says in fact they no longer even support Windows and Mac: >> "Implementations of the API are currently available for Solaris SPARC, >> Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so >> someone could support it. But I guess that's part of the reason RXTX >> exists! >> >> So one of Sun's own products, SunSPOT, has to use RXTX to get comm port >> support. >> >> The version we use is 2.0 from 11/15/1998. I have posted it on our >> website, which is within the terms of the license agreement contained >> therein (as I understand it). >> >> The last version of javaxcomm for Windows, 2.0.3, (for which I have just >> a ZIP with only the .class JAR file - no source or docs), has a readme >> with these comments: >> >> This distribution contains the comm.jar file original part >> of the COMMAPI 2.0.3 release. The 2.0.3 release itself is >> no longer distributed. comm.jar, which contains the comm >> API java class files (eg. Sun's binary implementation of the >> interface classes), is being made available, unsupported, >> with no obligation to fix bugs, at the request of the RXTX >> project. The RxTx project (http://www.rxtx.org ), uses the >> comm.jar class files, but provides their own native library >> components to provide support for other platforms. >> >> The 2.0.3 comm.jar is being provided in this way because >> as of COMMAPI 3.x, the java binary implementation forked and >> became incompatible with the RxTx project's native code. >> Due to the lack of a clear business case, and to resource >> constraints, no additional resources are being >> provided to provide an alternative engineering solution >> at the time of writing. >> >> RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: >> >> Ultimately the COMMAPI would be better served if a Java >> Community Process JSR (http://www.jcp.org) was opened and >> the COMMAPI was rearchitected to provide a more pluggable >> framework to improve cross-platform support. Such an >> architecture would embody a better defined and better >> documented SPI interface, including a way for comm. ports >> to be revealed to the client application through the API >> via platform-aware plugins. Similarly, native code used >> to access comm port in general could be handled more >> flexibly using a plugin model, whereby on any platform, >> multiple native modules could be in use simultaneously. >> >> Since there are now various ways serial ports can be implemented >> and accessed, modular comm. port JNI native libraries would be >> of benefit insofar as removing the burden of over-generalization >> from any single native component, or inversely, by relieving the >> implicit constraint that comm. drivers be accessed only via a >> monolithic mechanism, such as the UNIX vnode interface. >> >> paul.klissner at sun.com >> 6/10/06 >> >> I hope that is helpful! >> > > It would be nice to work with Sun to resolve those longstanding issues. > But it may not be practical unless the process goes as fast and painless > as the grandfathering of commapi did. > > Another option may be the old kaffe extensions that moved to gnu > classpathx. These don't have the native libraries but should provide > the 2.0 interface and the javax.comm.properties mechansim for SPI. > > http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Mon Aug 4 21:09:15 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 21:09:15 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? Message-ID: Hi Jim, I will not step into the javax.comm namespace without Sun's explicite permission. I fully understand the pain point you are trying to address. In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm Linux) - which remains an integral part of rxtx. At the time it was a win for Sun and rxtx. The Sun commapi license is/was fairly clear that rxtx should not step into that namespace. It made sense as Sun was active in that space and rxtx may go into another namespace - it was an experiment in working with Sun. This may sound silly looking at something that happened almost 10 years ago. In a community of respect which Sun helped create, there is no question about what to do. I hope eventually Sun will step up and do a right thing too. I agree that this is hurting the API more than helping it. There are also questions about how to replace the API in the long term which includes HID support which isn't going well so far. Others that can't even look at Sun's javax.comm today and can look at Kaffe's contribution to classpathx can easily work around such restrictions. On Mon, 4 Aug 2008, Jim Redman wrote: > Has there been any work/would it be possible, to layer a javacomm > look-alike on top of the GNU code? > > The goal is not to move the javax code forward, but to emulate the > "legacy" javax packages for people who still need this. > > Jim > > Trent Jarvi wrote: >> >> It would be nice to work with Sun to resolve those longstanding issues. >> But it may not be practical unless the process goes as fast and painless >> as the grandfathering of commapi did. >> >> Another option may be the old kaffe extensions that moved to gnu >> classpathx. These don't have the native libraries but should provide >> the 2.0 interface and the javax.comm.properties mechansim for SPI. >> >> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From florianmanschwetus at gmx.de Tue Aug 5 05:04:46 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 13:04:46 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: References: <48971C1F.9020806@gmx.de> Message-ID: <489833CE.1040801@gmx.de> Just look at sendCommand in this method I have to place a Thread.sleep(20) after each byte send to get working. Even the event based receive doesn't work fine but this could be may stupidness. The specifikation document (it is on the last pages of the manual) for the beamer could be found on: http://www.optoma.co.uk/support.aspx Florian Manschwetus Trent Jarvi schrieb: > > Hi Florian > > Sorry for the top post in advance. I worry you may not see my answer > under all your code :) > > I have not received this email before. This is 500k of code which I > don't have time to read. I can spend about 5 min on each hobby email > and still get to work in the morning. I have a couple suggestions for > how to get an answer. > > First, cut out your comments and extra code so you can demonstrate the > question (I might even glance and see what is wrong then). Don't go for > a working final product. Isolate the problem using a simple program and > then ask with that as an example. If I did what you just did, I'd have > to post 3/4 of a million lines of code :) > > Second, join the rxtx mail-list and ask there. This will give you 100x > more eyes. I'll also read and try to follow. > > -- > taj > > > > On Mon, 4 Aug 2008, Florian Manschwetus wrote: > >> It could be that my university account is blocked by filters so >> resending from here. >> >> >> Topic is to control Optoma HD80 beamer using rs232 serial chat. >> This code is able to detect power state and switch the beamer on / off. >> connected is the beamer using a digitus usb 2.0 serial adapter with an >> FT232 USB-Serial adapter the systems architecture is amd64. >> >> Please take a look in the sendCommand routine i have to place theire >> those Thread.sleep to get it working. >> Now the question is this correct or is there a better way to get this >> working correctly? >> >> In the javadoc coming with the install i found this: >> setBaudBase >> >> public boolean setBaudBase(int BaudBase) >> throws UnsupportedCommOperationException, >> java.io.IOException >> >> Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 >> before using. >> >> could this explain the error? >> I attached my java source and the protocol description for the beamer >> (available on vendor website). >> >> thx, >> Florian Manschwetus >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: TestRS232.java Type: text/x-java Size: 9143 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0092.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0093.bin From michael.erskine at ketech.com Tue Aug 5 05:53:49 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Tue, 5 Aug 2008 12:53:49 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489833CE.1040801@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> > Just look at sendCommand in this method I have to place a > Thread.sleep(20) after each byte send to get working. Even the event > based receive doesn't work fine but this could be may stupidness. Hi Florian, Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. Regards, Michael Erskine. From florianmanschwetus at gmx.de Tue Aug 5 07:28:15 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:28:15 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> Message-ID: <4898556F.8000208@gmx.de> Michael Erskine schrieb: >> Just look at sendCommand in this method I have to place a >> Thread.sleep(20) after each byte send to get working. Even the event >> based receive doesn't work fine but this could be may stupidness. > > Hi Florian, > > Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. > > Regards, > Michael Erskine. > Ok, sounds fine for the receiving problem. But why i have to wait after each byte when sending a command squence? (the for loop in send command) Florian > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/284f350c/attachment-0045.bin From florianmanschwetus at gmx.de Tue Aug 5 07:44:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:44:14 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <4898592E.2020908@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >>> Just look at sendCommand in this method I have to place a >>> Thread.sleep(20) after each byte send to get working. Even the event >>> based receive doesn't work fine but this could be may stupidness. >> >> Hi Florian, >> >> Yes, naturally you'll have to wait for a response from the other end. >> Why not wait for notification from the event thread perhaps using a >> BlockingDeque rather than your LinkedList. Generally I >> try to decouple all input and output streams: in your case your >> application is operating synchronously like the "expect" program >> (http://expect.nist.gov/) so waits (or timeouts) will need to be >> factored in. >> >> Regards, >> Michael Erskine. >> > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) > > Florian Furthermore there is this basic baud with this confusing javadoc entry: public boolean setBaudBase(int BaudBase) throws UnsupportedCommOperationException, java.io.IOException Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 before using. maybe this could explain something Florian >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/006c7425/attachment-0045.bin From jredman at ergotech.com Tue Aug 5 09:13:36 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 05 Aug 2008 09:13:36 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: Message-ID: <48986E20.3060104@ergotech.com> Trent, So two issues: 1) Technically I'm still not sure how easy/practical a layer would be. The problems are always classes like listeners, and wrapping returns of gnu.io classes. I really see it as a "delegate" type of concept. Any thoughts or ideas of the practicality of this approach? The idea is not to modify RXTX. 2) Javax. The javax namespace does seem to be in widespread use outside of Sun (the same is true for the java namespace). The classpath extensions, or some other location, should be interested in a JavaComm implementation even if it does have dependencies on RXTX. Would you have any philosophical objection to an approach like that? Of course, I suspect it might be better if someone with that authority at Sun would admit that the javax namespace is already in the wild and that there is no problem with it being used within RXTX. Jim Trent Jarvi wrote: > Hi Jim, > > I will not step into the javax.comm namespace without Sun's explicite > permission. I fully understand the pain point you are trying to address. > > In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm > Linux) - which remains an integral part of rxtx. At the time it was a win for > Sun and rxtx. > > The Sun commapi license is/was fairly clear that rxtx should not step into that > namespace. It made sense as Sun was active in that space and rxtx may go into > another namespace - it was an experiment in working with Sun. > > This may sound silly looking at something that happened almost 10 years ago. > In a community of respect which Sun helped create, there is no question about > what to do. I hope eventually Sun will step up and do a right thing too. > > I agree that this is hurting the API more than helping it. There are also > questions about how to replace the API in the long term which includes HID > support which isn't going well so far. > > Others that can't even look at Sun's javax.comm today and can look at Kaffe's > contribution to classpathx can easily work around such restrictions. > > On Mon, 4 Aug 2008, Jim Redman wrote: > >> Has there been any work/would it be possible, to layer a javacomm >> look-alike on top of the GNU code? >> >> The goal is not to move the javax code forward, but to emulate the >> "legacy" javax packages for people who still need this. >> >> Jim >> >> Trent Jarvi wrote: >>> It would be nice to work with Sun to resolve those longstanding issues. >>> But it may not be practical unless the process goes as fast and painless >>> as the grandfathering of commapi did. >>> >>> Another option may be the old kaffe extensions that moved to gnu >>> classpathx. These don't have the native libraries but should provide >>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>> >>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From sandeep at genevasoftech.com Tue Aug 5 11:18:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Tue, 05 Aug 2008 22:48:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <48988B6C.5080409@genevasoftech.com> Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. *-- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/ad20f1cb/attachment-0045.html From Martin.Oberhuber at windriver.com Tue Aug 5 13:30:17 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Tue, 5 Aug 2008 21:30:17 +0200 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Sandeep, shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on Sol7 but I've successfully run it on Sol9 and Sol10. Or is your request really about a native 64bit variant? I'm afraid that then you're out of luck since I think that quite a bit of RXTX is not yet ready for 64 bit. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Sandeep Kumar K Sent: Tuesday, August 05, 2008 7:19 PM To: rxtx at qbang.org Subject: [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so for Solaris 9 Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. -- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/81b7f988/attachment-0045.html From tjarvi at qbang.org Tue Aug 5 22:38:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 22:38:34 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 5 Aug 2008, Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built > on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid that > then > you're out of luck since I think that quite a bit of RXTX is not yet > ready > for 64 bit. > While rxtx-2.1-7 probably has problems, The CVS code should be OK for 64 bit Solaris. If it isn't, let me know and I'll find which patch is missing. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Aug 5 23:13:00 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 23:13:00 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48986E20.3060104@ergotech.com> References: <48986E20.3060104@ergotech.com> Message-ID: On Tue, 5 Aug 2008, Jim Redman wrote: > Trent, > > So two issues: > > 1) Technically I'm still not sure how easy/practical a layer would be. The > problems are always classes like listeners, and wrapping returns of gnu.io > classes. I really see it as a "delegate" type of concept. Any thoughts or > ideas of the practicality of this approach? The idea is not to modify RXTX. I have not put too much thought into this. I assume you want what rxtx 2.0 provided to tie into javax.comm implementations. More classes could be added to rxtx 2.1-7 for SPI support. Maintaining rxtx-2.0 could also be handed to someone if they like. > > 2) Javax. The javax namespace does seem to be in widespread use outside of > Sun (the same is true for the java namespace). The classpath extensions, or > some other location, should be interested in a JavaComm implementation even > if it does have dependencies on RXTX. Would you have any philosophical > objection to an approach like that? > No problems. Classpathx would be a possible place to do it. I'd suggest thinking twice about what this involves in practical terms. You would be wanting to revive the 2.0 API while Sun is at 3.0 and grandfathering the JSR. This undermines the main reason (established api) for using the javax.comm namespace and does not leave such a project in a good position. The only win I see here is maintaining support for applications that can't migrate namespaces. Not that that isn't important. At some point it is going to be less work to just edit the bytecode :) Such a javax.comm effort would also be signing up new projects that decided to use the work up for concerns they probably will not understand or expect. That probably isn't a good path to facilitate for new projects at this time. We will put a good faith effort to work well with others but keep in mind the project has limited bandwidth for such efforts. > Of course, I suspect it might be better if someone with that authority at Sun > would admit that the javax namespace is already in the wild and that there is > no problem with it being used within RXTX. > > Jim > > Trent Jarvi wrote: >> Hi Jim, >> >> I will not step into the javax.comm namespace without Sun's explicite >> permission. I fully understand the pain point you are trying to address. >> >> In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java >> Comm Linux) - which remains an integral part of rxtx. At the time it was a >> win for Sun and rxtx. >> >> The Sun commapi license is/was fairly clear that rxtx should not step into >> that namespace. It made sense as Sun was active in that space and rxtx may >> go into another namespace - it was an experiment in working with Sun. >> >> This may sound silly looking at something that happened almost 10 years >> ago. In a community of respect which Sun helped create, there is no >> question about what to do. I hope eventually Sun will step up and do a >> right thing too. >> >> I agree that this is hurting the API more than helping it. There are also >> questions about how to replace the API in the long term which includes HID >> support which isn't going well so far. >> >> Others that can't even look at Sun's javax.comm today and can look at >> Kaffe's contribution to classpathx can easily work around such >> restrictions. >> >> On Mon, 4 Aug 2008, Jim Redman wrote: >> >>> Has there been any work/would it be possible, to layer a javacomm >>> look-alike on top of the GNU code? >>> >>> The goal is not to move the javax code forward, but to emulate the >>> "legacy" javax packages for people who still need this. >>> >>> Jim >>> >>> Trent Jarvi wrote: >>>> It would be nice to work with Sun to resolve those longstanding issues. >>>> But it may not be practical unless the process goes as fast and painless >>>> as the grandfathering of commapi did. >>>> >>>> Another option may be the old kaffe extensions that moved to gnu >>>> classpathx. These don't have the native libraries but should provide >>>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>>> >>>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From sandeep at genevasoftech.com Wed Aug 6 00:03:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Wed, 06 Aug 2008 11:33:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: <48993EB8.30107@genevasoftech.com> Thank you Mr. Martin for your suggestion. The native file which is given in rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am getting the following error . Any suggestions to solve this issue. I am using Solaris SPARC 64 bit machine. ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) thrown while loading gnu.io.RXTXCommDriver Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(Unknown Source) at java.lang.ClassLoader.loadLibrary(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) at com.ReadFromModem.main(ReadFromModem.java:84) * * *Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid > that then > you're out of luck since I think that quite a bit of RXTX is not yet ready > for 64 bit. > > Cheers, > -- > *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > ------------------------------------------------------------------------ > *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On > Behalf Of *Sandeep Kumar K > *Sent:* Tuesday, August 05, 2008 7:19 PM > *To:* rxtx at qbang.org > *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so > for Solaris 9 > > Hi, > > Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 > bit machine. The librxtxSerial.so given in website is for Solaris 8. > > *-- > > Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/1e920343/attachment-0045.html From tjarvi at qbang.org Wed Aug 6 00:21:42 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 00:21:42 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <48993EB8.30107@genevasoftech.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> <48993EB8.30107@genevasoftech.com> Message-ID: Hi Sandeep You may be out of luck unless you can compile the 2.1 src in CVS (requires gnu make and gcc). But you could try the ToyBox(R)(TM) which is a collection of WiLdLy untested cross compiled 2.1-7 binaries covering everything from the ibm z series to embeded arm/ppc. To give an idea how poorly these are tested, I don't even know if z series machines have a serial port. ftp://www.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Solaris They should at least match the binary types. Actually, I think if you use the rxtx jar from CVS with that file, it should 'work' as the fix for 64 bits was in java not the native code. You could just cd rxtx*/src; javac *.java then jar -cf RXTXcomm.jar `find -name \*.class` to create the hybrid which will complain about version information a bit. On Wed, 6 Aug 2008, Sandeep Kumar K wrote: > Thank you Mr. Martin for your suggestion. The native file which is given in > rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am > getting the following error . > Any suggestions to solve this issue. > I am using Solaris SPARC 64 bit machine. > > ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar > java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 > (Possible cause: architecture word > width mismatch) thrown while loading gnu.io.RXTXCommDriver > Exception in thread "main" java.lang.UnsatisfiedLinkError: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF > class: ELFCLASS64 (Possible cause: > architecture word width mismatch) > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(Unknown Source) > at java.lang.ClassLoader.loadLibrary(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > at com.ReadFromModem.main(ReadFromModem.java:84) > > * > * > > *Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > > > Oberhuber, Martin wrote: >> Sandeep, >> shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse >> variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on >> Sol7 but I've successfully run it on Sol9 and Sol10. >> Or is your request really about a native 64bit variant? I'm afraid that >> then >> you're out of luck since I think that quite a bit of RXTX is not yet ready >> for 64 bit. >> Cheers, >> -- >> *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> ------------------------------------------------------------------------ >> *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On >> Behalf Of *Sandeep Kumar K >> *Sent:* Tuesday, August 05, 2008 7:19 PM >> *To:* rxtx at qbang.org >> *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so >> for Solaris 9 >> >> Hi, >> >> Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 >> bit machine. The librxtxSerial.so given in website is for Solaris 8. >> >> *-- >> Thanks & Regards >> >> Sandeep Kumar K >> Sr. Software Engineer >> Geneva Software Technologies >> Whitefield, Bangalore >> Mob : 9880193454* >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> From michael.erskine at ketech.com Wed Aug 6 01:39:28 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 6 Aug 2008 08:39:28 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Florian Manschwetus wrote: > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) Hi Florian, I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. Regards, Michael Erskine. From florianmanschwetus at gmx.de Wed Aug 6 02:53:16 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 06 Aug 2008 10:53:16 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Message-ID: <4899667C.6010706@gmx.de> Michael Erskine schrieb: > Florian Manschwetus wrote: >> Ok, sounds fine for the receiving problem. >> But why i have to wait after each byte when sending a command squence? >> (the for loop in send command) > > Hi Florian, > I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. > > Regards, > Michael Erskine. > correct with a terminal on the other end it works, my idea was that this basic baud has some influence. Could some one explain what it is for? Florian > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/c2b4fa84/attachment-0045.bin From rick_knight at rlknight.com Wed Aug 6 13:01:07 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:01:07 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F4F3.3020707@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > I have an application (Readerware) that uses RXTX with Javax to access the serial port. This used to work fine under previous Linux' and Java, but something has changed, I assume with Java itself , that is causing the application to fail with a link error. The application is not able to find librxtxSerialParallel.so. RXTX supplies librxtxSerial.so and librxtxParallel.so, but not librxtxSerialParallel.so. Where can I get librxtxSerialParallel.so, or do I need it? Is something else causing the lib to not be found? Thanks, Rick Knight From rick_knight at rlknight.com Wed Aug 6 13:17:55 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:17:55 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F8E3.5060400@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Thanks for the reply. The developer of the app I'm trying to use (Readerware) has sent me a copy of the comm.api and I've copied the library (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar into the proper places. When I try to run the application, I get this error... Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: /usr/lib/libSolarisSerialParallel.so: /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not little-endian (Possible cause: endianness mismatch) Caught java.lang.UnsatisfiedLinkError: com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I while loading driver com.sun.comm.SolarisDriver Is there a way around this error? Thanks again, Rick Knight From jlar310 at gmail.com Wed Aug 6 13:37:42 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 14:37:42 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899F8E3.5060400@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > The developer of the app I'm trying to use (Readerware) has sent me a > copy of the comm.api and I've copied the library > (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar > into the proper places. When I try to run the application, I get this > error... > > Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: > /usr/lib/libSolarisSerialParallel.so: > /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not > little-endian (Possible cause: endianness mismatch) > Caught java.lang.UnsatisfiedLinkError: > com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I > > while loading driver com.sun.comm.SolarisDriver > > Is there a way around this error? What host OS are you running? From your original post it looks like 32 bit Linux. The libSolarisSerialParallel.so file is for Sun Solaris and will vary depending on the underlying hardware architecture as well. Sorry for the double post Rick, but I failed to send this to the list the first time... -- Jeff From rick_knight at rlknight.com Wed Aug 6 13:44:29 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:44:29 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: <4899FF1D.9030504@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > > >> The developer of the app I'm trying to use (Readerware) has sent me a >> copy of the comm.api and I've copied the library >> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >> into the proper places. When I try to run the application, I get this >> error... >> >> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >> /usr/lib/libSolarisSerialParallel.so: >> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >> little-endian (Possible cause: endianness mismatch) >> Caught java.lang.UnsatisfiedLinkError: >> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >> >> while loading driver com.sun.comm.SolarisDriver >> >> Is there a way around this error? >> > > What host OS are you running? From your original post it looks like 32 > bit Linux. > > The libSolarisSerialParallel.so file is for Sun Solaris and will vary > depending on the underlying hardware architecture as well. > > I'm running Kubuntu Linux (debian based). It's 32 bit. Rick Knight From jlar310 at gmail.com Wed Aug 6 15:33:23 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 16:33:23 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > I don't think Sun did binary libraries for Linux in the 2.0 version. Can someone with more historical experience than I confirm that? I recently tried to port a Comm API application from Solaris sparc to Linux x86 and likewise could not get my hands on the binary libraries. I eventually just re-wrote the code to use the gnu namespace packages and rxtx 2.1. What I don't understand is why your application vendor does not provide everything you need to run their software. FYI: I have librxtxParallel.so and librxtxSerial.so installed at JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is /usr/java/default which is actually a softlink to /usr/java/jre1.6.0_05. -- Jeff From defiantlew at yahoo.com.au Wed Aug 6 16:29:33 2008 From: defiantlew at yahoo.com.au (Lew L) Date: Thu, 7 Aug 2008 08:29:33 +1000 Subject: [Rxtx] Sun's Comm API Documentation References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> Message-ID: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> As a matter of interest is the Sun Comm API documentation available somewhere? I have tried the Sun site but it seems to have been removed. Unless I have missed the documentation for RXTX? I javadocced the RXTX source but information (to me) is minimal. Somewhere I got the impression that the Sun Comm API docs is, or was, compatible with RXTX, what is the best docs to use in conjuntion with RXTX and where may the be available? Cheers Lew From rick_knight at rlknight.com Wed Aug 6 17:18:33 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:18:33 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A3149.4050306@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff I'm not sure if I posted this here or not, but when I try to build RXTX from source I get this install error... make all-am make[1]: Entering directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' make[1]: Nothing to be done for `all-am'. make[1]: Leaving directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 Can you tell me how to get past this error and get RXTX built and installed? Thanks, Rick From bboyes at systronix.com Wed Aug 6 17:40:12 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Wed, 06 Aug 2008 17:40:12 -0600 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: At 16:29 08/06/2008, Lew L wrote: >As a matter of interest is the Sun Comm API documentation available >somewhere? I have tried the Sun site but it seems to have been removed. It's in the file we have posted, link in prev email (sorry, in a huge hurry right now). Javadocs definitely there. >Unless I have missed the documentation for RXTX? I javadocced the RXTX >source but information (to me) is minimal. >Somewhere I got the impression that the Sun Comm API docs is, or was, >compatible with RXTX, what is the best docs to use in conjuntion with RXTX >and where may the be available? Yeah, this is one of my concerns/beefs. There is little documentation for RXTX and it isn't just the same as javaxcomm. I would be willing to help out writing docs for RXTX! Yes really... esp if we can fix the Bluetooth issues. best regards Bruce >Cheers >Lew > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx ------- WWW.SYSTRONIX.COM ---------- Real embedded Java and much more +1-801-534-1017 Salt Lake City, USA From rick_knight at rlknight.com Wed Aug 6 17:54:08 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:54:08 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A39A0.2090309@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff, I would like for my vendor to switch to rxtx 2.1. It would make things much easier for me. I'm not sure why he's still using the javax compatible code. He's a small operation. Re-writing the code to use gnu namespace sounds like a major overhaul. Was it? Thanks, Rick From tjarvi at qbang.org Wed Aug 6 21:35:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:35:12 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: >> >>> Jeff wrote: >>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>>> >>>> >>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things > much easier for me. I'm not sure why he's still using the javax > compatible code. He's a small operation. Re-writing the code to use gnu > namespace sounds like a major overhaul. Was it? > Hi Jeff, The changes are fairly mechanical. Imports need to change and any explicite use of the namespace needs to change such as catching an exception. The following script was made for maintaining rxtx 2.0 but can apply to other needs. It is in the contrib dir with rxtx source. #!/bin/sh # Don't use! :) # # Sat, 03 May 2003 16:45:08 Modifications from J?rg Weule # Create a ed-cmd for the change of one pattern # case $1 in gnu) X=g/javax_comm/s+javax_comm+gnu_io+g ;; javax) X=g/gnu_io/s+gnu_io+javax_comm+g ;; *) echo;echo;echo From the top rxtx directory run;echo;echo -e \\t./ChangePackage.sh gnu;echo -e \\t\\tor;echo -e \\t./ChangePackage.sh javax;echo;echo; exit 0 ;; esac # # ed will be used to keep the owner and mode of the files unchanged. # We have run the ed-script for the characters '.' '/' as well. # "tr _ $D" do the change. # find . -type f -a -print | grep -v $0 | (while read F ; do ( echo $X; echo $X| tr _ /; echo $X| tr _ .; echo w; echo q ) | ed $F 2>&1 >/dev/null done ) # # Now we do little changes at the Makefiles. Hope that all we need. # find . -name Makefile\* -a -print | (while read F ; do cat < References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: On Thu, 7 Aug 2008, Lew L wrote: > As a matter of interest is the Sun Comm API documentation available > somewhere? I have tried the Sun site but it seems to have been removed. > > Unless I have missed the documentation for RXTX? I javadocced the RXTX > source but information (to me) is minimal. > Somewhere I got the impression that the Sun Comm API docs is, or was, > compatible with RXTX, what is the best docs to use in conjuntion with RXTX > and where may the be available? > Hi Lew, The documentation on Sun's website is accurate. The changes that are problematic in 3.0 are on the backside which rxtx used to plug into. http://java.sun.com/products/javacomm/reference/api/index.html CommPortIdentifier may have some minor differences (judging by the authors notes). -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Aug 6 21:46:08 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:46:08 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > If javax.comm.properties is properly installed and you are using a 2.0 version of Sun's commapi with rxtx 2.0, you should not see the library attempt to load libSolarisSerialParallel.so. Sun CommAPI 3.0 will not work with any version of rxtx as it is hard coded to use the shared library. See the INSTALL file with rxtx-2.0 source for more help with the properties file. -- Trent Jarvi tjarvi at qbang.org From jlar310 at gmail.com Thu Aug 7 06:32:06 2008 From: jlar310 at gmail.com (Jeff) Date: Thu, 7 Aug 2008 07:32:06 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > Jeff wrote: >> >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >> wrote: >> >>> >>> Jeff wrote: >>> >>>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>> wrote: >>>> >>>> >>>> >>>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things much > easier for me. I'm not sure why he's still using the javax compatible code. > He's a small operation. Re-writing the code to use gnu namespace sounds like > a major overhaul. Was it? I found it quite easy. In fact, in order to accommodate the transition, I actually separated all of the code that deals directly with the Comm API or RXTX into a helper class. The helper class was then coded to use reflection to determine which library was available and then instantiate the necessary objects. No direct imports of either library are used. The main application just needs to get it's hands on the IO streams and need not deal directly with the libraries. Other programs may not be so simple... But this doesn't really help you unless your vendor forks over the source code... -- Jeff From rick_knight at rlknight.com Thu Aug 7 09:47:12 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Thu, 07 Aug 2008 08:47:12 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: <489B1900.10108@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >>> wrote: >>> >>> >>>> Jeff wrote: >>>> >>>> >>>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>>> copy of the comm.api and I've copied the library >>>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>>> into the proper places. When I try to run the application, I get this >>>>>> error... >>>>>> >>>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>>> /usr/lib/libSolarisSerialParallel.so: >>>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>>> little-endian (Possible cause: endianness mismatch) >>>>>> Caught java.lang.UnsatisfiedLinkError: >>>>>> >>>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>>> >>>>>> while loading driver com.sun.comm.SolarisDriver >>>>>> >>>>>> Is there a way around this error? >>>>>> >>>>>> >>>>>> >>>>> What host OS are you running? From your original post it looks like 32 >>>>> bit Linux. >>>>> >>>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>>> depending on the underlying hardware architecture as well. >>>>> >>>>> >>>>> >>>>> >>>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>>> >>>> >>>> >>> I don't think Sun did binary libraries for Linux in the 2.0 version. >>> Can someone with more historical experience than I confirm that? >>> >>> I recently tried to port a Comm API application from Solaris sparc to >>> Linux x86 and likewise could not get my hands on the binary libraries. >>> I eventually just re-wrote the code to use the gnu namespace packages >>> and rxtx 2.1. >>> >>> What I don't understand is why your application vendor does not >>> provide everything you need to run their software. >>> >>> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >>> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >>> /usr/java/default which is actually a softlink to >>> /usr/java/jre1.6.0_05. >>> >>> >>> >> Jeff, >> >> I would like for my vendor to switch to rxtx 2.1. It would make things much >> easier for me. I'm not sure why he's still using the javax compatible code. >> He's a small operation. Re-writing the code to use gnu namespace sounds like >> a major overhaul. Was it? >> > > I found it quite easy. In fact, in order to accommodate the > transition, I actually separated all of the code that deals directly > with the Comm API or RXTX into a helper class. The helper class was > then coded to use reflection to determine which library was available > and then instantiate the necessary objects. No direct imports of > either library are used. The main application just needs to get it's > hands on the IO streams and need not deal directly with the libraries. > Other programs may not be so simple... > > But this doesn't really help you unless your vendor forks over the > source code... > > Jeff, This may not help me directly, but I'm going to forward this thread to the vendor. I think he'll be open to making things work. Thanks again, Rick Knight From agusmunioz at gmail.com Thu Aug 7 16:39:51 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Thu, 7 Aug 2008 19:39:51 -0300 Subject: [Rxtx] How to send ack? Message-ID: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Hi, I'm still learning about serial communication and I have some doubts. I've got this question about how to do the following thing in rxtx. I have this hardware that connect to a PC using a serial port. These hardware receives data from a telephone line, proccess it, and then send it forward to the serial port. I've used a program named wincomm that shows what information is send it through the serial port and I have the nex behaviour: The hardware has a buffer where all data is stored, that cannot be sent it through the seria port. The program reads the first data send it by the hardware, and keep reading the same data always. There is a button in the application that says enable Ack, and when I click, then the hardware start to send all the stored information, and all the information is shown. I write a class, using rxtx that reads the serial port, and the same thing happens, it remains reading the same (first) data all the time. And I thing something like the enable Ack I'm missing. How can I do this enable Ack from my java code using rxtx? Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080807/e0a0f9a1/attachment-0043.html From ajmas at sympatico.ca Thu Aug 7 18:26:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 7 Aug 2008 20:26:41 -0400 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: <4BF42297-81E2-4BB8-A89F-1D43588379AE@sympatico.ca> On 6-Aug-08, at 19:40 , Bruce Boyes wrote: >> Unless I have missed the documentation for RXTX? I javadocced the >> RXTX >> source but information (to me) is minimal. >> Somewhere I got the impression that the Sun Comm API docs is, or was, >> compatible with RXTX, what is the best docs to use in conjuntion >> with RXTX >> and where may the be available? > > Yeah, this is one of my concerns/beefs. There is little documentation > for RXTX and it isn't just the same as javaxcomm. > > I would be willing to help out writing docs for RXTX! Yes really... > esp if we can fix the Bluetooth issues. If you want to contribute documentation then the best place to do that is the wiki. If there is anything missing or that could be improved on then please do so. If there are any points that you would like to see improved, for which you don't have the knowledge then ask on the mailing list for a volunteer. Andre From florianmanschwetus at gmx.de Fri Aug 8 03:04:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Fri, 08 Aug 2008 11:04:14 +0200 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Message-ID: <489C0C0E.2020401@gmx.de> Agustin Mu?oz schrieb: > Hi, I'm still learning about serial communication and I have some > doubts. I've got this question about how to do the following thing in rxtx. > I have this hardware that connect to a PC using a serial port. These > hardware receives data from a telephone line, proccess it, and then send > it forward to the serial port. I've used a program named wincomm that > shows what information is send it through the serial port and I have the > nex behaviour: > > The hardware has a buffer where all data is stored, that cannot be sent > it through the seria port. > The program reads the first data send it by the hardware, and keep > reading the same data always. > There is a button in the application that says enable Ack, and when I > click, then the hardware start to send all the stored information, and > all the information is shown. > > I write a class, using rxtx that reads the serial port, and the same > thing happens, it remains reading the same (first) data all the time. > And I thing something like the enable Ack I'm missing. > How can I do this enable Ack from my java code using rxtx? Afaik, a look at man ascii reveals: Okt Dez Hex Char 006 6 06 ACK So, i hope this will do the job: send(6); florian > > Thanks in advance > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/5b4965f8/attachment-0043.bin From agusmunioz at gmail.com Fri Aug 8 16:31:00 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 19:31:00 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <489C0C0E.2020401@gmx.de> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> Message-ID: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Hi Florian, thanks for the answer. By send(6) you mean to get the port OutputStream and write a 6? I try that but it didn't work. Any suggestion? Thanks On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < florianmanschwetus at gmx.de> wrote: > Agustin Mu?oz schrieb: > > Hi, I'm still learning about serial communication and I have some doubts. >> I've got this question about how to do the following thing in rxtx. >> I have this hardware that connect to a PC using a serial port. These >> hardware receives data from a telephone line, proccess it, and then send it >> forward to the serial port. I've used a program named wincomm that shows >> what information is send it through the serial port and I have the nex >> behaviour: >> >> The hardware has a buffer where all data is stored, that cannot be sent >> it through the seria port. >> The program reads the first data send it by the hardware, and keep reading >> the same data always. >> There is a button in the application that says enable Ack, and when I >> click, then the hardware start to send all the stored information, and all >> the information is shown. >> >> I write a class, using rxtx that reads the serial port, and the same thing >> happens, it remains reading the same (first) data all the time. And I thing >> something like the enable Ack I'm missing. >> How can I do this enable Ack from my java code using rxtx? >> > Afaik, a look at man ascii reveals: > Okt Dez Hex Char > 006 6 06 ACK > So, i hope this will do the job: > send(6); > > florian > >> >> Thanks in advance >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/7f3fba42/attachment-0042.html From agusmunioz at gmail.com Fri Aug 8 18:39:27 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 21:39:27 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Message-ID: <988288430808081739x7f9e7889id82591d5a9e2b4f6@mail.gmail.com> Ok, Florian, it works!! my problem was that I've been sending, through the OutputStream, the bytes of 6 as a string: out.write("6".getBytes()); but then I realized that you can write an int on an OuptuStream, so I tried that and It works: out.write(6); Thank you for the guidance!! On Fri, Aug 8, 2008 at 7:31 PM, Agustin Mu?oz wrote: > Hi Florian, thanks for the answer. By send(6) you mean to get the port > OutputStream and write a 6? > > I try that but it didn't work. > > Any suggestion? > > Thanks > > > On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < > florianmanschwetus at gmx.de> wrote: > >> Agustin Mu?oz schrieb: >> >> Hi, I'm still learning about serial communication and I have some doubts. >>> I've got this question about how to do the following thing in rxtx. >>> I have this hardware that connect to a PC using a serial port. These >>> hardware receives data from a telephone line, proccess it, and then send it >>> forward to the serial port. I've used a program named wincomm that shows >>> what information is send it through the serial port and I have the nex >>> behaviour: >>> >>> The hardware has a buffer where all data is stored, that cannot be sent >>> it through the seria port. >>> The program reads the first data send it by the hardware, and keep >>> reading the same data always. >>> There is a button in the application that says enable Ack, and when I >>> click, then the hardware start to send all the stored information, and all >>> the information is shown. >>> >>> I write a class, using rxtx that reads the serial port, and the same >>> thing happens, it remains reading the same (first) data all the time. And I >>> thing something like the enable Ack I'm missing. >>> How can I do this enable Ack from my java code using rxtx? >>> >> Afaik, a look at man ascii reveals: >> Okt Dez Hex Char >> 006 6 06 ACK >> So, i hope this will do the job: >> send(6); >> >> florian >> >>> >>> Thanks in advance >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/b918ab3d/attachment-0042.html From florianmanschwetus at gmx.de Sat Aug 9 00:45:43 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Sat, 09 Aug 2008 08:45:43 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4899667C.6010706@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> Message-ID: <489D3D17.9090209@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >> Florian Manschwetus wrote: >>> Ok, sounds fine for the receiving problem. >>> But why i have to wait after each byte when sending a command squence? >>> (the for loop in send command) >> >> Hi Florian, >> I'd imagine you probably don't! You could send all bytes in one go and >> RXTX would send them. The problem is most probably the other end: >> perhaps it has a really small buffer, some non-standard UART, or a >> crazy timing issue. If you attach a terminal to your output and send >> all the bytes of a command in one go they should appear no problem. >> >> Regards, >> Michael Erskine. >> > correct with a terminal on the other end it works, my idea was that this > basic baud has some influence. Could some one explain what it is for? > > Florian To make it more clear, my problem is that i can't use: outputStream.write(byte[]); => Beamer doesn't understand the sequence. (mostly no answer when he answers then *001) when i use this construct instead: for (int i = 0; i < command.length; i++) { this.outputStream.write(command[i]); try { Thread.sleep(25); } catch (InterruptedException e) { // TODO Auto-generated catch block e.printStackTrace(); } } it works nearly reliable. So what could it be? This Basic Baud is what exactly? Florian -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080809/692304ee/attachment-0042.bin From tjarvi at qbang.org Sat Aug 9 16:37:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Aug 2008 16:37:19 -0600 (MDT) Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489D3D17.9090209@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> <489D3D17.9090209@gmx.de> Message-ID: On Sat, 9 Aug 2008, Florian Manschwetus wrote: > Florian Manschwetus schrieb: >> Michael Erskine schrieb: >>> Florian Manschwetus wrote: >>>> Ok, sounds fine for the receiving problem. >>>> But why i have to wait after each byte when sending a command squence? >>>> (the for loop in send command) >>> >>> Hi Florian, >>> I'd imagine you probably don't! You could send all bytes in one go and >>> RXTX would send them. The problem is most probably the other end: perhaps >>> it has a really small buffer, some non-standard UART, or a crazy timing >>> issue. If you attach a terminal to your output and send all the bytes of a >>> command in one go they should appear no problem. >>> >>> Regards, >>> Michael Erskine. >>> >> correct with a terminal on the other end it works, my idea was that this >> basic baud has some influence. Could some one explain what it is for? >> >> Florian > To make it more clear, > my problem is that i can't use: > outputStream.write(byte[]); > => Beamer doesn't understand the sequence. (mostly no answer when he answers > then *001) > > when i use this construct instead: > > for (int i = 0; i < command.length; i++) { > this.outputStream.write(command[i]); > try { > Thread.sleep(25); > } catch (InterruptedException e) { > // TODO Auto-generated catch block > e.printStackTrace(); > } > } > > it works nearly reliable. > > So what could it be? This Basic Baud is what exactly? > I suspect you are using the 'moon protocol' and don't know it. RXTX enables this by default. The buffer on the other end is first in first out while reading. If the buffer is full, the bits are hand carried to the moon and burried. Then if the other side reads a couple bytes, two more bytes go into the buffer followed by more moon protocol. The resulting array of bytes the other side reads may appear to be scrambled until you go to the moon, get the bits and insert them in the right place. Flow control can prevent the default moon protocol and throttles the communiation by almost writing a byte at a time as need be. Hardware flow control is preferable but software flow control should also work. Read and write can appear to hang if the other side is not connected. This is why we don't enable them all the time. If you can't use flow control, you have to take care with the moon protocol and give the other side time to read. That is what your slower version of write is doing. -- Trent Jarvi tjarvi at qbang.org From rxtx at allenjb.me.uk Mon Aug 11 08:06:36 2008 From: rxtx at allenjb.me.uk (AllenJB) Date: Mon, 11 Aug 2008 15:06:36 +0100 Subject: [Rxtx] Disabling EV_RXFLAG Message-ID: <48A0476C.2090800@allenjb.me.uk> Hi all, I'm working with a device which does not use an EvtChar and need to disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an event mask of FD 01 00 00. The reference software I have uses FB 00 00 00. With the rxtx mask I get framing errors which I believe are caused when the EvtChar is received. Is there currently a way with rxtx (I've using rxtx from Java) to disable EV_RXFLAG? If not from Java, where would I start if I wanted to turn the EV_RXFLAG option off in the C code? I've had a grep of the rxtx source code, but I can't see where EV_RXFLAG is being set. Thanks in advance, AllenJB From tjarvi at qbang.org Mon Aug 11 14:17:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Aug 2008 14:17:27 -0600 (MDT) Subject: [Rxtx] Disabling EV_RXFLAG In-Reply-To: <48A0476C.2090800@allenjb.me.uk> References: <48A0476C.2090800@allenjb.me.uk> Message-ID: On Mon, 11 Aug 2008, AllenJB wrote: > Hi all, > > I'm working with a device which does not use an EvtChar and need to > disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an > event mask of FD 01 00 00. The reference software I have uses FB 00 00 > 00. With the rxtx mask I get framing errors which I believe are caused > when the EvtChar is received. > > Is there currently a way with rxtx (I've using rxtx from Java) to > disable EV_RXFLAG? > > If not from Java, where would I start if I wanted to turn the EV_RXFLAG > option off in the C code? I've had a grep of the rxtx source code, but I > can't see where EV_RXFLAG is being set. > > Thanks in advance, > > AllenJB Hi Allen, I'd look at termios.c::tcsetattr() and termios.c::FillDCB() -- Trent Jarvi tjarvi at qbang.org From superdadusa at gmail.com Tue Aug 12 13:57:32 2008 From: superdadusa at gmail.com (John Choi) Date: Tue, 12 Aug 2008 13:57:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. Message-ID: Hi all, Just let you all know I just start to learn Java. I have download the serial comm package and the source code from open source communities.. I was able to verify with the given message string via serial monitor. when the given message string sends to the serial port then the character return added to the end of string by default if I use "Hello World" however if I changed to something else other than "Hello, World" there is no character return add to the end of string. I thing the library download from rxtx.org has implemented for the special strings. I can do like "login\n" in the string message to make character return but I don't want to add this individual custom character for each command return in every static message string I send, Can any who have done this might help me? Basically, something like this,, Write and add function to the program write a command, Reads the respond from a serial device.. Function handles multiple messages, Write: "com open" Read: Welcome to my world" expected Write: "admin" Read: Password?, expected Write: "admin" Read: you are successfully login terminal, expected. And I need to add a separate function handler handles a character return add to the each command above. If anyone can help this I can do the reset? Thank you in advance, John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0038.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SerialIO.java Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0038.pl From Steffen.DETTMER at ingenico.com Wed Aug 13 02:16:38 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 13 Aug 2008 10:16:38 +0200 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: References: Message-ID: <20080813081638.GA25412@elberon.bln.de.ingenico.com> * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > I can do like "login\n" in the string message to make character > return but I don't want to add this individual custom character > for each command return in every static message string I send, and why not?! > Can any who have done this might help me? what's about with writing a small wrapper function adding the carriage return? However, this would be slow, because either you call write two times (very bad) or the string needs to be copied, \n appended and written (since you are using Java Performance probably isn't so critical). Personally I would write `"login\n"' and `username + "\n"' etc., because since it is part of the command it should be part of the command definition string. > Basically, something like this,, Write and add function to the program write > a command, Reads the respond from a serial device.. correctly reading a `line' is more difficult. If you cannot make assumptions about timeouts and/or you need to have low delay, you need to read byte wise. If you need to save CPU resources you might need to add some buffering layer that you can read byte-wise but that is reading blockwise with some small timeout (lets say for serial lines something around byte transmission time times three or so). > /* > * To change this template, choose Tools | Templates > * and open the template in the editor. > */ :) > package joliba; > > /** > * > * @author root > */ :) > // derived from SUN's examples in the javax.comm package > import java.io.*; > import java.util.*; > //import javax.comm.*; // for SUN's serial/parallel port libraries > import gnu.io.*; // for rxtxSerial library > > public class SerialIO implements Runnable, SerialPortEventListener { > static CommPortIdentifier portId; > static CommPortIdentifier saveportId; > static Enumeration portList; > InputStream inputStream; > SerialPort serialPort; > Thread readThread; You need a thread for your synchronous RPC-style protocol? > static String messageString = "Hello, world!"; > static OutputStream outputStream; > static boolean outputBufferEmptyFlag = false; > > public static void main(String[] args) { > boolean portFound = false; > String defaultPort; > > // determine the name of the serial port on several operating systems > String osname = System.getProperty("os.name","").toLowerCase(); > if ( osname.startsWith("windows") ) { > // windows > defaultPort = "COM1"; > } else if (osname.startsWith("linux")) { > // linux > defaultPort = "/dev/ttyS0"; > } else if ( osname.startsWith("mac") ) { > // mac > defaultPort = "????"; > } else { > System.out.println("Sorry, your operating system is not supported"); > return; > } Is such a construction recommended? Isn't there some abstraction (like COM1 working on any platform)? [...] > try { > // activate the OUTPUT_BUFFER_EMPTY notifier > serialPort.notifyOnOutputEmpty(true); > } catch (Exception e) { > System.out.println("Error setting event notification"); > System.out.println(e.toString()); > System.exit(-1); > } I doubt that -1 is defined, probably some 127 or so would be the result, maybe better simply `throw e'? > public void writetoport() { > System.out.println("Writing \""+messageString+"\" to "+serialPort.getName()); > try { > // write string to serial port > outputStream.write(messageString.getBytes()); > } catch (IOException e) {} > } maybe something like /** * Writes the given output string and an additional carriage * return to the current outputStream. */ public void writeStringToPort( /** The output string (without CR). */ String output ) throws IOException { String outputLine = output + "\n"; outputStream.write(outputLine.getBytes()); } ? > > public SerialIO() { > // initalize serial port > try { > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > } catch (PortInUseException e) {} if the port is in use, you continue? Wonder that this works in Java, I would assume serialPort beeing uninitialized which AFAIK is an error in Java. > try { > inputStream = serialPort.getInputStream(); > } catch (IOException e) {} > > try { > serialPort.addEventListener(this); > } catch (TooManyListenersException e) {} > > // activate the DATA_AVAILABLE notifier > serialPort.notifyOnDataAvailable(true); > > try { > // set port parameters > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > } catch (UnsupportedCommOperationException e) {} > > // start the read thread > readThread = new Thread(this); > readThread.start(); > > } I think in all those exception cases you can abort, because it is unlikely that ignoring those errors allow a successful continuation, so in this case maybe it would be better to add a throw clause to the method. > public void run() { > // first thing in the thread, we initialize the write operation > initwritetoport(); > try { > while (true) { > // write string to port, the serialEvent will read it > writetoport(); > Thread.sleep(1000); > } > } catch (InterruptedException e) {} > } Does this make sense? Your `SimpleReadApp' writes one and the same string each second? > public void serialEvent(SerialPortEvent event) { > switch (event.getEventType()) { > case SerialPortEvent.BI: > case SerialPortEvent.OE: > case SerialPortEvent.FE: > case SerialPortEvent.PE: > case SerialPortEvent.CD: > case SerialPortEvent.CTS: > case SerialPortEvent.DSR: > case SerialPortEvent.RI: > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > break; > case SerialPortEvent.DATA_AVAILABLE: > // we get here if data has been received > byte[] readBuffer = new byte[20]; > try { > // read data > while (inputStream.available() > 0) { > int numBytes = inputStream.read(readBuffer); > } > // print data > String result = new String(readBuffer); > System.out.println("Read: "+result); > } catch (IOException e) {} I doubt that this is correct. I would assume you will get a 20 bytes result always, if more bytes would be available they would be printed in a second line but if less bytes are read I'd assume that the buffer/result contains zero bytes from implicite readBuffer contents initialisation (zero is no string terminator in Java AFAIK). > break; > } > } > } oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From florianmanschwetus at gmx.de Wed Aug 13 06:09:31 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 13 Aug 2008 14:09:31 +0200 Subject: [Rxtx] someone has seen such errors? Message-ID: <48A2CEFB.90007@gmx.de> I mean my communication mostly works, but it is far from perfect could this be the reason? Florian Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/949b9947/attachment-0038.bin From superdadusa at gmail.com Wed Aug 13 08:40:32 2008 From: superdadusa at gmail.com (John Choi) Date: Wed, 13 Aug 2008 08:40:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: <20080813081638.GA25412@elberon.bln.de.ingenico.com> References: <20080813081638.GA25412@elberon.bln.de.ingenico.com> Message-ID: Thank you so much Steffen and I will try that suggestion. John On 8/13/08, Steffen DETTMER wrote: > > * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > > I can do like "login\n" in the string message to make character > > return but I don't want to add this individual custom character > > for each command return in every static message string I send, > > and why not?! > > > Can any who have done this might help me? > > what's about with writing a small wrapper function adding the > carriage return? > However, this would be slow, because either you call write two > times (very bad) or the string needs to be copied, \n appended > and written (since you are using Java Performance probably isn't > so critical). > > Personally I would write `"login\n"' and `username + "\n"' etc., > because since it is part of the command it should be part of the > command definition string. > > > Basically, something like this,, Write and add function to the program > write > > a command, Reads the respond from a serial device.. > > correctly reading a `line' is more difficult. If you cannot make > assumptions about timeouts and/or you need to have low delay, you > need to read byte wise. If you need to save CPU resources you > might need to add some buffering layer that you can read > byte-wise but that is reading blockwise with some small timeout > (lets say for serial lines something around byte transmission > time times three or so). > > > /* > > * To change this template, choose Tools | Templates > > * and open the template in the editor. > > */ > > :) > > > package joliba; > > > > /** > > * > > * @author root > > */ > > :) > > > // derived from SUN's examples in the javax.comm package > > import java.io.*; > > import java.util.*; > > //import javax.comm.*; // for SUN's serial/parallel port libraries > > import gnu.io.*; // for rxtxSerial library > > > > public class SerialIO implements Runnable, SerialPortEventListener { > > static CommPortIdentifier portId; > > static CommPortIdentifier saveportId; > > static Enumeration portList; > > InputStream inputStream; > > SerialPort serialPort; > > Thread readThread; > > You need a thread for your synchronous RPC-style protocol? > > > static String messageString = "Hello, world!"; > > static OutputStream outputStream; > > static boolean outputBufferEmptyFlag = false; > > > > public static void main(String[] args) { > > boolean portFound = false; > > String defaultPort; > > > > // determine the name of the serial port on several operating > systems > > String osname = System.getProperty("os.name","").toLowerCase(); > > if ( osname.startsWith("windows") ) { > > // windows > > defaultPort = "COM1"; > > } else if (osname.startsWith("linux")) { > > // linux > > defaultPort = "/dev/ttyS0"; > > } else if ( osname.startsWith("mac") ) { > > // mac > > defaultPort = "????"; > > } else { > > System.out.println("Sorry, your operating system is not > supported"); > > return; > > } > > Is such a construction recommended? Isn't there some abstraction > (like COM1 working on any platform)? > > [...] > > try { > > // activate the OUTPUT_BUFFER_EMPTY notifier > > serialPort.notifyOnOutputEmpty(true); > > } catch (Exception e) { > > System.out.println("Error setting event notification"); > > System.out.println(e.toString()); > > System.exit(-1); > > } > > I doubt that -1 is defined, probably some 127 or so would be the > result, maybe better simply `throw e'? > > > public void writetoport() { > > System.out.println("Writing \""+messageString+"\" to > "+serialPort.getName()); > > try { > > // write string to serial port > > outputStream.write(messageString.getBytes()); > > } catch (IOException e) {} > > } > > maybe something like > > /** > * Writes the given output string and an additional carriage > * return to the current outputStream. > */ > public void > writeStringToPort( > /** The output string (without CR). */ > String output > ) throws IOException > { > String outputLine = output + "\n"; > outputStream.write(outputLine.getBytes()); > } > > ? > > > > > public SerialIO() { > > // initalize serial port > > try { > > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > > } catch (PortInUseException e) {} > > if the port is in use, you continue? Wonder that this works in > Java, I would assume serialPort beeing uninitialized which AFAIK > is an error in Java. > > > try { > > inputStream = serialPort.getInputStream(); > > } catch (IOException e) {} > > > > try { > > serialPort.addEventListener(this); > > } catch (TooManyListenersException e) {} > > > > // activate the DATA_AVAILABLE notifier > > serialPort.notifyOnDataAvailable(true); > > > > try { > > // set port parameters > > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > } catch (UnsupportedCommOperationException e) {} > > > > // start the read thread > > readThread = new Thread(this); > > readThread.start(); > > > > } > > I think in all those exception cases you can abort, because it is > unlikely that ignoring those errors allow a successful > continuation, so in this case maybe it would be better to add a > throw clause to the method. > > > public void run() { > > // first thing in the thread, we initialize the write operation > > initwritetoport(); > > try { > > while (true) { > > // write string to port, the serialEvent will read it > > writetoport(); > > Thread.sleep(1000); > > } > > } catch (InterruptedException e) {} > > } > > Does this make sense? Your `SimpleReadApp' writes one and the > same string each second? > > > public void serialEvent(SerialPortEvent event) { > > switch (event.getEventType()) { > > case SerialPortEvent.BI: > > case SerialPortEvent.OE: > > case SerialPortEvent.FE: > > case SerialPortEvent.PE: > > case SerialPortEvent.CD: > > case SerialPortEvent.CTS: > > case SerialPortEvent.DSR: > > case SerialPortEvent.RI: > > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > > break; > > case SerialPortEvent.DATA_AVAILABLE: > > // we get here if data has been received > > byte[] readBuffer = new byte[20]; > > try { > > // read data > > while (inputStream.available() > 0) { > > int numBytes = inputStream.read(readBuffer); > > } > > // print data > > String result = new String(readBuffer); > > System.out.println("Read: "+result); > > } catch (IOException e) {} > > I doubt that this is correct. I would assume you will get a 20 > bytes result always, if more bytes would be available they would > be printed in a second line but if less bytes are read I'd assume > that the buffer/result contains zero bytes from implicite > readBuffer contents initialisation (zero is no string terminator > in Java AFAIK). > > > break; > > } > > } > > } > > oki, > > Steffen > > About Ingenico Throughout the world businesses rely on Ingenico for secure > and expedient electronic transaction acceptance. Ingenico products leverage > proven technology, established standards and unparalleled ergonomics to > provide optimal reliability, versatility and usability. This comprehensive > range of products is complemented by a global array of services and > partnerships, enabling businesses in a number of vertical sectors to accept > transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged > information. If you are not the addressee or authorized to receive this for > the addressee, you must not use, copy, disclose or take any action based on > this message or any information herein. If you have received this message in > error, please advise the sender immediately by reply e-mail and delete this > message. Thank you for your cooperation. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/73c4135c/attachment-0037.html From ajmas at sympatico.ca Sat Aug 16 07:15:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 09:15:41 -0400 Subject: [Rxtx] someone has seen such errors? In-Reply-To: <48A2CEFB.90007@gmx.de> References: <48A2CEFB.90007@gmx.de> Message-ID: <43B5E8DA-1D93-4D90-809B-AAF35FF724C5@sympatico.ca> On 13-Aug-08, at 08:09 , Florian Manschwetus wrote: > I mean my communication mostly works, but it is far from perfect > could this be the reason? > > Florian > > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control Judging by the error messages this looks related to the driver you are using. Do a search for the following string with you favourite search engine, it should turn up a few hits: ftdi_set_termios FAILED to set databits/stopbits/parity Andre From ajmas at sympatico.ca Sat Aug 16 19:12:04 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 21:12:04 -0400 Subject: [Rxtx] Using SerialPortEvent? Message-ID: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Hi, Could someone tell me how I should be using the SerialPortEvent? Am I meant to be waiting for data and then simply reading from the inputstream? If this is the case why no just block on an inputstream read? Andr? From tjarvi at qbang.org Sat Aug 16 19:41:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 16 Aug 2008 19:41:13 -0600 (MDT) Subject: [Rxtx] Using SerialPortEvent? In-Reply-To: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> References: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Message-ID: On Sat, 16 Aug 2008, Andre-John Mas wrote: > Hi, > > Could someone tell me how I should be using the SerialPortEvent? Am I > meant to be waiting for data and then simply reading from the > inputstream? If this is the case why no just block on an inputstream > read? > Polling for data is fine also. It really depends upon what you are trying to do. For instance, if you require x bytes before reading, you can start polling after data is available. If you read on the same thread as your GUI and are waiting for data in a read, the results may be less than desirable. Java programming is 'usually' event driven rather than polling based. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sat Aug 16 20:10:39 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 22:10:39 -0400 Subject: [Rxtx] Using SerialPortEvent? In-Reply-To: References: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Message-ID: <3E495D4C-BB28-4845-A6AB-984C9A826BDF@sympatico.ca> On 16-Aug-08, at 21:41 , Trent Jarvi wrote: > On Sat, 16 Aug 2008, Andre-John Mas wrote: > >> Hi, >> >> Could someone tell me how I should be using the SerialPortEvent? Am I >> meant to be waiting for data and then simply reading from the >> inputstream? If this is the case why no just block on an inputstream >> read? >> > > Polling for data is fine also. It really depends upon what you are > trying to do. For instance, if you require x bytes before reading, > you can start polling after data is available. If you read on the > same thread as your GUI and are waiting for data in a read, the > results may be less than desirable. > > Java programming is 'usually' event driven rather than polling based. Sounds good. I thought I would use this opportunity to provide a event based version of the TwoWaySerialComm example. Could you just validate it before I add it to the Wiki: package ajmas74.experimental; import gnu.io.CommPort; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; import gnu.io.SerialPortEvent; import gnu.io.SerialPortEventListener; import java.io.IOException; import java.io.InputStream; import java.io.OutputStream; /** * This version of the TwoWaySerialComm example makes use of the * SerialPortEventListener to avoid polling. * * @author ajmas * */ public class TwoWaySerialComm { public TwoWaySerialComm() { super(); } void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { CommPort commPort = portIdentifier.open(this.getClass().getName(),2000); if ( commPort instanceof SerialPort ) { SerialPort serialPort = (SerialPort) commPort; serialPort .setSerialPortParams (57600 ,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); (new Thread(new SerialWriter(out))).start(); serialPort.addEventListener(new SerialReader(in)); } else { System.out.println("Error: Only serial ports are handled by this example."); } } } /** * Handles the input coming from the serial port. A new line character * is treated as the end of a block in this example. */ public static class SerialReader implements SerialPortEventListener { private InputStream in; private byte[] buffer = new byte[1024]; public SerialReader ( InputStream in ) { this.in = in; } public void serialEvent(SerialPortEvent arg0) { int data; try { int len = 0; while ( ( data = in.read()) > -1 ) { if ( data != '\n' ) { break; } buffer[len++] = (byte) data; } System.out.print(new String(buffer,0,len)); } catch ( IOException e ) { e.printStackTrace(); System.exit(-1); } } } /** */ public static class SerialWriter implements Runnable { OutputStream out; public SerialWriter ( OutputStream out ) { this.out = out; } public void run () { try { int c = 0; while ( ( c = System.in.read()) > -1 ) { this.out.write(c); } } catch ( IOException e ) { e.printStackTrace(); System.exit(-1); } } } public static void main ( String[] args ) { try { (new TwoWaySerialComm()).connect("COM3"); } catch ( Exception e ) { e.printStackTrace(); } } } From lfarkas at lfarkas.org Tue Aug 19 07:32:59 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Tue, 19 Aug 2008 15:32:59 +0200 Subject: [Rxtx] JNI or CNI Message-ID: <48AACB8B.9060606@lfarkas.org> hi, what is the current recommended way to rxtx on linux JNI or it's better to use CNI? is the CNI version fully functional and the same level as the JNI? i currently try to make a rhel/centos/fedora rpm for rxtx but has many problems with the standard dir structure. yours. -- Levente "Si vis pacem para bellum!" From lfarkas at lfarkas.org Tue Aug 19 08:47:34 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Tue, 19 Aug 2008 16:47:34 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel Message-ID: <48AADD06.7040809@lfarkas.org> hi, newer or not so newer linux kernel do not contain the UTS_RELEASE so the current rxtx is not compile on the latest kernels. even if it's commented out in the cvs configure there are other places. i attcahed a patch which fix it (or at least doesn't cause error at non-debug build). ps. is there any plan to the new 2.1-8 release in the near future? there are many changes (at least the license change in all file and in this case create a diff is very difficult)? the latest release more then 2 years old:-( -- Levente "Si vis pacem para bellum!" -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-2.1-uts.patch Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080819/ab5d38ac/attachment-0031.pl From ajmas at sympatico.ca Tue Aug 19 16:21:53 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 19 Aug 2008 18:21:53 -0400 Subject: [Rxtx] Event based example Message-ID: <24735BFB-B088-4B84-8173-FE98DF63B12F@sympatico.ca> Hi, I have just posted an example of using SerialPortEventListener in the Wiki: http://rxtx.qbang.org/wiki/index.php/Event_Based_Two_Way_Communication If you see any issues please could you let me know, or makes the changes. Andre From Martin.Oberhuber at windriver.com Fri Aug 22 04:02:24 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 22 Aug 2008 12:02:24 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <48AADD06.7040809@lfarkas.org> References: <48AADD06.7040809@lfarkas.org> Message-ID: <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> Farkas, there are indeed efforts to get a new RXTX release out the door. Your experience as a package maintainer would likely be helpful during these efforts, since I'd think it makes sense to keep the patches minimal that you must make to have the source compile in your environment. What are the things that you find problematic, apart from the UTS thing that you have mentioned before? What is the timing that you have in mind for your package? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Farkas Levente > Sent: Tuesday, August 19, 2008 4:48 PM > To: rxtx at qbang.org > Subject: [Rxtx] UTS_RELEASE not defined in newer kernel > > hi, > newer or not so newer linux kernel do not contain the > UTS_RELEASE so the > current rxtx is not compile on the latest kernels. even if it's > commented out in the cvs configure there are other places. > i attcahed a patch which fix it (or at least doesn't cause error at > non-debug build). > > ps. is there any plan to the new 2.1-8 release in the near > future? there > are many changes (at least the license change in all file and in this > case create a diff is very difficult)? the latest release more then 2 > years old:-( > > -- > Levente "Si vis pacem para bellum!" > From lfarkas at lfarkas.org Fri Aug 22 04:36:26 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Fri, 22 Aug 2008 12:36:26 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> References: <48AADD06.7040809@lfarkas.org> <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> Message-ID: <48AE96AA.6090505@lfarkas.org> hi, the packages already build for fedora-9 and centos-5 and here: http://www.lfarkas.org/linux/packages/ what i've to patch, the UTS, the configure script, but it's already fixed in the cvs (in another way) and the loadlibrary. the reasons for last one can be found here: https://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_files_that_use_JNI after we test it i'd like to add these packages to fedora and epel main repository (that's why it's be useful a new release after 2 years:-) imho versions are cheap and why not just release 2.1-8? the real code changes are minimal and if something critical bug found still can release 2.1-9:-) ps. and would be better to use simple number for version like 2.1-7 rather then 2.1-7v2. Oberhuber, Martin wrote: > Farkas, > > there are indeed efforts to get a new RXTX release out the > door. Your experience as a package maintainer would likely > be helpful during these efforts, since I'd think it makes > sense to keep the patches minimal that you must make to > have the source compile in your environment. > > What are the things that you find problematic, apart from > the UTS thing that you have mentioned before? > > What is the timing that you have in mind for your package? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >> On Behalf Of Farkas Levente >> Sent: Tuesday, August 19, 2008 4:48 PM >> To: rxtx at qbang.org >> Subject: [Rxtx] UTS_RELEASE not defined in newer kernel >> >> hi, >> newer or not so newer linux kernel do not contain the >> UTS_RELEASE so the >> current rxtx is not compile on the latest kernels. even if it's >> commented out in the cvs configure there are other places. >> i attcahed a patch which fix it (or at least doesn't cause error at >> non-debug build). >> >> ps. is there any plan to the new 2.1-8 release in the near >> future? there >> are many changes (at least the license change in all file and in this >> case create a diff is very difficult)? the latest release more then 2 >> years old:-( >> >> -- >> Levente "Si vis pacem para bellum!" >> -- Levente "Si vis pacem para bellum!" From tjarvi at qbang.org Fri Aug 22 18:50:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Aug 2008 18:50:32 -0600 (MDT) Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <48AE96AA.6090505@lfarkas.org> References: <48AADD06.7040809@lfarkas.org> <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> <48AE96AA.6090505@lfarkas.org> Message-ID: Hi Farkas, The v2 was simply the second build - no code changes. We are comming out with a new release shortly. I would encourage working with distros as you are. The building of rxtx turns out to be a bottle neck in quick releases. We do want stable releases that work for a year or more but I would have no problems with quicker cycles on developing work. I would have no problem working with someone that did builds that receive less testing more often but they do have to come out for multiple platforms from this end. Thanks for the links. On Fri, 22 Aug 2008, Farkas Levente wrote: > hi, > the packages already build for fedora-9 and centos-5 and here: > http://www.lfarkas.org/linux/packages/ > what i've to patch, the UTS, the configure script, but it's already > fixed in the cvs (in another way) and the loadlibrary. the reasons for > last one can be found here: > https://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_files_that_use_JNI > after we test it i'd like to add these packages to fedora and epel main > repository (that's why it's be useful a new release after 2 years:-) > imho versions are cheap and why not just release 2.1-8? the real code > changes are minimal and if something critical bug found still can > release 2.1-9:-) > > ps. and would be better to use simple number for version like 2.1-7 > rather then 2.1-7v2. > > Oberhuber, Martin wrote: >> Farkas, >> >> there are indeed efforts to get a new RXTX release out the >> door. Your experience as a package maintainer would likely >> be helpful during these efforts, since I'd think it makes >> sense to keep the patches minimal that you must make to >> have the source compile in your environment. >> >> What are the things that you find problematic, apart from >> the UTS thing that you have mentioned before? >> >> What is the timing that you have in mind for your package? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >>> On Behalf Of Farkas Levente >>> Sent: Tuesday, August 19, 2008 4:48 PM >>> To: rxtx at qbang.org >>> Subject: [Rxtx] UTS_RELEASE not defined in newer kernel >>> >>> hi, >>> newer or not so newer linux kernel do not contain the >>> UTS_RELEASE so the >>> current rxtx is not compile on the latest kernels. even if it's >>> commented out in the cvs configure there are other places. >>> i attcahed a patch which fix it (or at least doesn't cause error at >>> non-debug build). >>> >>> ps. is there any plan to the new 2.1-8 release in the near >>> future? there >>> are many changes (at least the license change in all file and in this >>> case create a diff is very difficult)? the latest release more then 2 >>> years old:-( >>> >>> -- >>> Levente "Si vis pacem para bellum!" >>> > > > From andy at triera.net Sat Aug 23 15:17:44 2008 From: andy at triera.net (Andy Rozman) Date: Sat, 23 Aug 2008 21:17:44 +0000 Subject: [Rxtx] port not identified on FreeBSD In-Reply-To: References: Message-ID: <48B07E78.2030306@triera.net> Hi ! I have one small problem... I have started using FreeBSD in last few days and I have come accross a problem with rxtx on FreeBSD. I am using usb-to-serial converter, which is identified under FreeBSD without problem as ucom0, and creates link under /dev called ttyU0, which is correct way to be done under FreeBSD (if device would be unidentified it would be called ugen0 - as usb generic). Problem is that I say to rxtx to get my all serial ports this one is not among them. Which names are permissable under linux-like implementations? Which will be accepted as serial ports? Andy From tjarvi at qbang.org Sat Aug 23 13:57:45 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 23 Aug 2008 13:57:45 -0600 (MDT) Subject: [Rxtx] port not identified on FreeBSD In-Reply-To: <48B07E78.2030306@triera.net> References: <48B07E78.2030306@triera.net> Message-ID: On Sat, 23 Aug 2008, Andy Rozman wrote: > Hi ! > > I have one small problem... I have started using FreeBSD in last few > days and I have come accross a problem with rxtx on FreeBSD. > > I am using usb-to-serial converter, which is identified under FreeBSD > without problem as ucom0, and creates link under /dev called > ttyU0, which is correct way to be done under FreeBSD (if device would be > unidentified it would be called ugen0 - as usb generic). Problem is that > I say to rxtx to get my all serial ports this one is not among them. > Which names are permissable under linux-like implementations? Which will > be accepted as serial ports? > > Andy > Thanks Andy! We will add ttyU* to FreeBSD. For now you can use properties to enable the port. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting#How_does_rxtx_detect_ports.3F__Can_I_override_it.3F The fix: diff -u -r1.16.2.59 RXTXCommDriver.java --- RXTXCommDriver.java 18 Nov 2007 22:32:41 -0000 1.16.2.59 +++ RXTXCommDriver.java 23 Aug 2008 19:55:25 -0000 @@ -644,6 +644,7 @@ { String[] Temp = { "ttyd", //general purpose serial ports + "ttyU", //general purpose USB serial ports "cuaa", //dialout serial ports "ttyA", //Specialix SI/XIO dialin ports "cuaA", //Specialix SI/XIO dialout ports -- Trent Jarvi tjarvi at qbang.org From rick_knight at rlknight.com Mon Aug 4 13:25:10 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Mon, 04 Aug 2008 12:25:10 -0700 Subject: [Rxtx] Sun's Comm API? Message-ID: <48975796.4010600@rlknight.com> I have an application that requires the javax compatible version of RXTX and Sun's comm api. I've been able to download and extract the version of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api anywhere. Can someone tell me where I can find it? Or maybe send me a copy? Also, when I try to build RXTX, configure and make complete successfully but make install failes with this error libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 I've never come accross this error before. How can I get past it? Thanks, Rick From bboyes at systronix.com Mon Aug 4 19:10:01 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:10:01 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48975796.4010600@rlknight.com> References: <48975796.4010600@rlknight.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/cb9c6167/attachment-0047.html From bboyes at systronix.com Mon Aug 4 19:12:37 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:12:37 -0600 Subject: [Rxtx] Towards an RXTX release - CSR BT/USB chipset In-Reply-To: <488FB7E7.8000802@gmail.com> References: <460801A4097E3D4CA04CC64EE648584806C56CF0@ism-mail03.corp.ad.wrs.com> <13557-75390@sneakemail.com> <20980-23424@sneakemail.com> <488FB7E7.8000802@gmail.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/52236088/attachment-0047.html From tjarvi at qbang.org Mon Aug 4 19:42:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 19:42:21 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: On Mon, 4 Aug 2008, Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: > I have an application that requires the javax compatible > version of RXTX > and Sun's comm api. I've been able to download and extract > the version > of RXTX that I need (2.0-7pre2) but I can't find Sun's camm > api > anywhere. Can someone tell me where I can find it? Or maybe > send me a > > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm port > support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have just > a ZIP with only the .class JAR file - no source or docs), has a readme > with these comments: > > This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release.? The 2.0.3 release itself is > no longer distributed.? comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project.? The RxTx project (http://www.rxtx.org ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org) was opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support.? Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins.? Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > ? > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > I hope that is helpful! > It would be nice to work with Sun to resolve those longstanding issues. But it may not be practical unless the process goes as fast and painless as the grandfathering of commapi did. Another option may be the old kaffe extensions that moved to gnu classpathx. These don't have the native libraries but should provide the 2.0 interface and the javax.comm.properties mechansim for SPI. http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Mon Aug 4 20:23:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Mon, 04 Aug 2008 20:23:57 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4897B9BD.5070809@ergotech.com> Has there been any work/would it be possible, to layer a javacomm look-alike on top of the GNU code? The goal is not to move the javax code forward, but to emulate the "legacy" javax packages for people who still need this. Jim Trent Jarvi wrote: > On Mon, 4 Aug 2008, Bruce Boyes wrote: > >> At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible >> version of RXTX >> and Sun's comm api. I've been able to download and extract >> the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm >> api >> anywhere. Can someone tell me where I can find it? Or maybe >> send me a >> >> >> javaxcomm has had a sort of on-again off-again history. The windoze >> version has been languishing for years (literally) but there are newer >> versions for other OS's. >> >> We try to keep links on one of our help pages current: >> http://www.practicalembeddedjava.com/tools/javatools_list.html >> which gets you to here: >> http://java.sun.com/products/javacomm/ >> where it says in fact they no longer even support Windows and Mac: >> "Implementations of the API are currently available for Solaris SPARC, >> Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so >> someone could support it. But I guess that's part of the reason RXTX >> exists! >> >> So one of Sun's own products, SunSPOT, has to use RXTX to get comm port >> support. >> >> The version we use is 2.0 from 11/15/1998. I have posted it on our >> website, which is within the terms of the license agreement contained >> therein (as I understand it). >> >> The last version of javaxcomm for Windows, 2.0.3, (for which I have just >> a ZIP with only the .class JAR file - no source or docs), has a readme >> with these comments: >> >> This distribution contains the comm.jar file original part >> of the COMMAPI 2.0.3 release. The 2.0.3 release itself is >> no longer distributed. comm.jar, which contains the comm >> API java class files (eg. Sun's binary implementation of the >> interface classes), is being made available, unsupported, >> with no obligation to fix bugs, at the request of the RXTX >> project. The RxTx project (http://www.rxtx.org ), uses the >> comm.jar class files, but provides their own native library >> components to provide support for other platforms. >> >> The 2.0.3 comm.jar is being provided in this way because >> as of COMMAPI 3.x, the java binary implementation forked and >> became incompatible with the RxTx project's native code. >> Due to the lack of a clear business case, and to resource >> constraints, no additional resources are being >> provided to provide an alternative engineering solution >> at the time of writing. >> >> RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: >> >> Ultimately the COMMAPI would be better served if a Java >> Community Process JSR (http://www.jcp.org) was opened and >> the COMMAPI was rearchitected to provide a more pluggable >> framework to improve cross-platform support. Such an >> architecture would embody a better defined and better >> documented SPI interface, including a way for comm. ports >> to be revealed to the client application through the API >> via platform-aware plugins. Similarly, native code used >> to access comm port in general could be handled more >> flexibly using a plugin model, whereby on any platform, >> multiple native modules could be in use simultaneously. >> >> Since there are now various ways serial ports can be implemented >> and accessed, modular comm. port JNI native libraries would be >> of benefit insofar as removing the burden of over-generalization >> from any single native component, or inversely, by relieving the >> implicit constraint that comm. drivers be accessed only via a >> monolithic mechanism, such as the UNIX vnode interface. >> >> paul.klissner at sun.com >> 6/10/06 >> >> I hope that is helpful! >> > > It would be nice to work with Sun to resolve those longstanding issues. > But it may not be practical unless the process goes as fast and painless > as the grandfathering of commapi did. > > Another option may be the old kaffe extensions that moved to gnu > classpathx. These don't have the native libraries but should provide > the 2.0 interface and the javax.comm.properties mechansim for SPI. > > http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Mon Aug 4 21:09:15 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 21:09:15 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? Message-ID: Hi Jim, I will not step into the javax.comm namespace without Sun's explicite permission. I fully understand the pain point you are trying to address. In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm Linux) - which remains an integral part of rxtx. At the time it was a win for Sun and rxtx. The Sun commapi license is/was fairly clear that rxtx should not step into that namespace. It made sense as Sun was active in that space and rxtx may go into another namespace - it was an experiment in working with Sun. This may sound silly looking at something that happened almost 10 years ago. In a community of respect which Sun helped create, there is no question about what to do. I hope eventually Sun will step up and do a right thing too. I agree that this is hurting the API more than helping it. There are also questions about how to replace the API in the long term which includes HID support which isn't going well so far. Others that can't even look at Sun's javax.comm today and can look at Kaffe's contribution to classpathx can easily work around such restrictions. On Mon, 4 Aug 2008, Jim Redman wrote: > Has there been any work/would it be possible, to layer a javacomm > look-alike on top of the GNU code? > > The goal is not to move the javax code forward, but to emulate the > "legacy" javax packages for people who still need this. > > Jim > > Trent Jarvi wrote: >> >> It would be nice to work with Sun to resolve those longstanding issues. >> But it may not be practical unless the process goes as fast and painless >> as the grandfathering of commapi did. >> >> Another option may be the old kaffe extensions that moved to gnu >> classpathx. These don't have the native libraries but should provide >> the 2.0 interface and the javax.comm.properties mechansim for SPI. >> >> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From florianmanschwetus at gmx.de Tue Aug 5 05:04:46 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 13:04:46 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: References: <48971C1F.9020806@gmx.de> Message-ID: <489833CE.1040801@gmx.de> Just look at sendCommand in this method I have to place a Thread.sleep(20) after each byte send to get working. Even the event based receive doesn't work fine but this could be may stupidness. The specifikation document (it is on the last pages of the manual) for the beamer could be found on: http://www.optoma.co.uk/support.aspx Florian Manschwetus Trent Jarvi schrieb: > > Hi Florian > > Sorry for the top post in advance. I worry you may not see my answer > under all your code :) > > I have not received this email before. This is 500k of code which I > don't have time to read. I can spend about 5 min on each hobby email > and still get to work in the morning. I have a couple suggestions for > how to get an answer. > > First, cut out your comments and extra code so you can demonstrate the > question (I might even glance and see what is wrong then). Don't go for > a working final product. Isolate the problem using a simple program and > then ask with that as an example. If I did what you just did, I'd have > to post 3/4 of a million lines of code :) > > Second, join the rxtx mail-list and ask there. This will give you 100x > more eyes. I'll also read and try to follow. > > -- > taj > > > > On Mon, 4 Aug 2008, Florian Manschwetus wrote: > >> It could be that my university account is blocked by filters so >> resending from here. >> >> >> Topic is to control Optoma HD80 beamer using rs232 serial chat. >> This code is able to detect power state and switch the beamer on / off. >> connected is the beamer using a digitus usb 2.0 serial adapter with an >> FT232 USB-Serial adapter the systems architecture is amd64. >> >> Please take a look in the sendCommand routine i have to place theire >> those Thread.sleep to get it working. >> Now the question is this correct or is there a better way to get this >> working correctly? >> >> In the javadoc coming with the install i found this: >> setBaudBase >> >> public boolean setBaudBase(int BaudBase) >> throws UnsupportedCommOperationException, >> java.io.IOException >> >> Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 >> before using. >> >> could this explain the error? >> I attached my java source and the protocol description for the beamer >> (available on vendor website). >> >> thx, >> Florian Manschwetus >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: TestRS232.java Type: text/x-java Size: 9143 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0094.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0095.bin From michael.erskine at ketech.com Tue Aug 5 05:53:49 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Tue, 5 Aug 2008 12:53:49 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489833CE.1040801@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> > Just look at sendCommand in this method I have to place a > Thread.sleep(20) after each byte send to get working. Even the event > based receive doesn't work fine but this could be may stupidness. Hi Florian, Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. Regards, Michael Erskine. From florianmanschwetus at gmx.de Tue Aug 5 07:28:15 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:28:15 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> Message-ID: <4898556F.8000208@gmx.de> Michael Erskine schrieb: >> Just look at sendCommand in this method I have to place a >> Thread.sleep(20) after each byte send to get working. Even the event >> based receive doesn't work fine but this could be may stupidness. > > Hi Florian, > > Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. > > Regards, > Michael Erskine. > Ok, sounds fine for the receiving problem. But why i have to wait after each byte when sending a command squence? (the for loop in send command) Florian > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/284f350c/attachment-0046.bin From florianmanschwetus at gmx.de Tue Aug 5 07:44:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:44:14 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <4898592E.2020908@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >>> Just look at sendCommand in this method I have to place a >>> Thread.sleep(20) after each byte send to get working. Even the event >>> based receive doesn't work fine but this could be may stupidness. >> >> Hi Florian, >> >> Yes, naturally you'll have to wait for a response from the other end. >> Why not wait for notification from the event thread perhaps using a >> BlockingDeque rather than your LinkedList. Generally I >> try to decouple all input and output streams: in your case your >> application is operating synchronously like the "expect" program >> (http://expect.nist.gov/) so waits (or timeouts) will need to be >> factored in. >> >> Regards, >> Michael Erskine. >> > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) > > Florian Furthermore there is this basic baud with this confusing javadoc entry: public boolean setBaudBase(int BaudBase) throws UnsupportedCommOperationException, java.io.IOException Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 before using. maybe this could explain something Florian >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/006c7425/attachment-0046.bin From jredman at ergotech.com Tue Aug 5 09:13:36 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 05 Aug 2008 09:13:36 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: Message-ID: <48986E20.3060104@ergotech.com> Trent, So two issues: 1) Technically I'm still not sure how easy/practical a layer would be. The problems are always classes like listeners, and wrapping returns of gnu.io classes. I really see it as a "delegate" type of concept. Any thoughts or ideas of the practicality of this approach? The idea is not to modify RXTX. 2) Javax. The javax namespace does seem to be in widespread use outside of Sun (the same is true for the java namespace). The classpath extensions, or some other location, should be interested in a JavaComm implementation even if it does have dependencies on RXTX. Would you have any philosophical objection to an approach like that? Of course, I suspect it might be better if someone with that authority at Sun would admit that the javax namespace is already in the wild and that there is no problem with it being used within RXTX. Jim Trent Jarvi wrote: > Hi Jim, > > I will not step into the javax.comm namespace without Sun's explicite > permission. I fully understand the pain point you are trying to address. > > In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm > Linux) - which remains an integral part of rxtx. At the time it was a win for > Sun and rxtx. > > The Sun commapi license is/was fairly clear that rxtx should not step into that > namespace. It made sense as Sun was active in that space and rxtx may go into > another namespace - it was an experiment in working with Sun. > > This may sound silly looking at something that happened almost 10 years ago. > In a community of respect which Sun helped create, there is no question about > what to do. I hope eventually Sun will step up and do a right thing too. > > I agree that this is hurting the API more than helping it. There are also > questions about how to replace the API in the long term which includes HID > support which isn't going well so far. > > Others that can't even look at Sun's javax.comm today and can look at Kaffe's > contribution to classpathx can easily work around such restrictions. > > On Mon, 4 Aug 2008, Jim Redman wrote: > >> Has there been any work/would it be possible, to layer a javacomm >> look-alike on top of the GNU code? >> >> The goal is not to move the javax code forward, but to emulate the >> "legacy" javax packages for people who still need this. >> >> Jim >> >> Trent Jarvi wrote: >>> It would be nice to work with Sun to resolve those longstanding issues. >>> But it may not be practical unless the process goes as fast and painless >>> as the grandfathering of commapi did. >>> >>> Another option may be the old kaffe extensions that moved to gnu >>> classpathx. These don't have the native libraries but should provide >>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>> >>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From sandeep at genevasoftech.com Tue Aug 5 11:18:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Tue, 05 Aug 2008 22:48:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <48988B6C.5080409@genevasoftech.com> Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. *-- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/ad20f1cb/attachment-0046.html From Martin.Oberhuber at windriver.com Tue Aug 5 13:30:17 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Tue, 5 Aug 2008 21:30:17 +0200 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Sandeep, shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on Sol7 but I've successfully run it on Sol9 and Sol10. Or is your request really about a native 64bit variant? I'm afraid that then you're out of luck since I think that quite a bit of RXTX is not yet ready for 64 bit. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Sandeep Kumar K Sent: Tuesday, August 05, 2008 7:19 PM To: rxtx at qbang.org Subject: [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so for Solaris 9 Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. -- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/81b7f988/attachment-0046.html From tjarvi at qbang.org Tue Aug 5 22:38:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 22:38:34 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 5 Aug 2008, Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built > on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid that > then > you're out of luck since I think that quite a bit of RXTX is not yet > ready > for 64 bit. > While rxtx-2.1-7 probably has problems, The CVS code should be OK for 64 bit Solaris. If it isn't, let me know and I'll find which patch is missing. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Aug 5 23:13:00 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 23:13:00 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48986E20.3060104@ergotech.com> References: <48986E20.3060104@ergotech.com> Message-ID: On Tue, 5 Aug 2008, Jim Redman wrote: > Trent, > > So two issues: > > 1) Technically I'm still not sure how easy/practical a layer would be. The > problems are always classes like listeners, and wrapping returns of gnu.io > classes. I really see it as a "delegate" type of concept. Any thoughts or > ideas of the practicality of this approach? The idea is not to modify RXTX. I have not put too much thought into this. I assume you want what rxtx 2.0 provided to tie into javax.comm implementations. More classes could be added to rxtx 2.1-7 for SPI support. Maintaining rxtx-2.0 could also be handed to someone if they like. > > 2) Javax. The javax namespace does seem to be in widespread use outside of > Sun (the same is true for the java namespace). The classpath extensions, or > some other location, should be interested in a JavaComm implementation even > if it does have dependencies on RXTX. Would you have any philosophical > objection to an approach like that? > No problems. Classpathx would be a possible place to do it. I'd suggest thinking twice about what this involves in practical terms. You would be wanting to revive the 2.0 API while Sun is at 3.0 and grandfathering the JSR. This undermines the main reason (established api) for using the javax.comm namespace and does not leave such a project in a good position. The only win I see here is maintaining support for applications that can't migrate namespaces. Not that that isn't important. At some point it is going to be less work to just edit the bytecode :) Such a javax.comm effort would also be signing up new projects that decided to use the work up for concerns they probably will not understand or expect. That probably isn't a good path to facilitate for new projects at this time. We will put a good faith effort to work well with others but keep in mind the project has limited bandwidth for such efforts. > Of course, I suspect it might be better if someone with that authority at Sun > would admit that the javax namespace is already in the wild and that there is > no problem with it being used within RXTX. > > Jim > > Trent Jarvi wrote: >> Hi Jim, >> >> I will not step into the javax.comm namespace without Sun's explicite >> permission. I fully understand the pain point you are trying to address. >> >> In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java >> Comm Linux) - which remains an integral part of rxtx. At the time it was a >> win for Sun and rxtx. >> >> The Sun commapi license is/was fairly clear that rxtx should not step into >> that namespace. It made sense as Sun was active in that space and rxtx may >> go into another namespace - it was an experiment in working with Sun. >> >> This may sound silly looking at something that happened almost 10 years >> ago. In a community of respect which Sun helped create, there is no >> question about what to do. I hope eventually Sun will step up and do a >> right thing too. >> >> I agree that this is hurting the API more than helping it. There are also >> questions about how to replace the API in the long term which includes HID >> support which isn't going well so far. >> >> Others that can't even look at Sun's javax.comm today and can look at >> Kaffe's contribution to classpathx can easily work around such >> restrictions. >> >> On Mon, 4 Aug 2008, Jim Redman wrote: >> >>> Has there been any work/would it be possible, to layer a javacomm >>> look-alike on top of the GNU code? >>> >>> The goal is not to move the javax code forward, but to emulate the >>> "legacy" javax packages for people who still need this. >>> >>> Jim >>> >>> Trent Jarvi wrote: >>>> It would be nice to work with Sun to resolve those longstanding issues. >>>> But it may not be practical unless the process goes as fast and painless >>>> as the grandfathering of commapi did. >>>> >>>> Another option may be the old kaffe extensions that moved to gnu >>>> classpathx. These don't have the native libraries but should provide >>>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>>> >>>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From sandeep at genevasoftech.com Wed Aug 6 00:03:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Wed, 06 Aug 2008 11:33:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: <48993EB8.30107@genevasoftech.com> Thank you Mr. Martin for your suggestion. The native file which is given in rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am getting the following error . Any suggestions to solve this issue. I am using Solaris SPARC 64 bit machine. ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) thrown while loading gnu.io.RXTXCommDriver Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(Unknown Source) at java.lang.ClassLoader.loadLibrary(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) at com.ReadFromModem.main(ReadFromModem.java:84) * * *Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid > that then > you're out of luck since I think that quite a bit of RXTX is not yet ready > for 64 bit. > > Cheers, > -- > *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > ------------------------------------------------------------------------ > *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On > Behalf Of *Sandeep Kumar K > *Sent:* Tuesday, August 05, 2008 7:19 PM > *To:* rxtx at qbang.org > *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so > for Solaris 9 > > Hi, > > Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 > bit machine. The librxtxSerial.so given in website is for Solaris 8. > > *-- > > Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/1e920343/attachment-0046.html From tjarvi at qbang.org Wed Aug 6 00:21:42 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 00:21:42 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <48993EB8.30107@genevasoftech.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> <48993EB8.30107@genevasoftech.com> Message-ID: Hi Sandeep You may be out of luck unless you can compile the 2.1 src in CVS (requires gnu make and gcc). But you could try the ToyBox(R)(TM) which is a collection of WiLdLy untested cross compiled 2.1-7 binaries covering everything from the ibm z series to embeded arm/ppc. To give an idea how poorly these are tested, I don't even know if z series machines have a serial port. ftp://www.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Solaris They should at least match the binary types. Actually, I think if you use the rxtx jar from CVS with that file, it should 'work' as the fix for 64 bits was in java not the native code. You could just cd rxtx*/src; javac *.java then jar -cf RXTXcomm.jar `find -name \*.class` to create the hybrid which will complain about version information a bit. On Wed, 6 Aug 2008, Sandeep Kumar K wrote: > Thank you Mr. Martin for your suggestion. The native file which is given in > rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am > getting the following error . > Any suggestions to solve this issue. > I am using Solaris SPARC 64 bit machine. > > ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar > java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 > (Possible cause: architecture word > width mismatch) thrown while loading gnu.io.RXTXCommDriver > Exception in thread "main" java.lang.UnsatisfiedLinkError: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF > class: ELFCLASS64 (Possible cause: > architecture word width mismatch) > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(Unknown Source) > at java.lang.ClassLoader.loadLibrary(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > at com.ReadFromModem.main(ReadFromModem.java:84) > > * > * > > *Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > > > Oberhuber, Martin wrote: >> Sandeep, >> shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse >> variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on >> Sol7 but I've successfully run it on Sol9 and Sol10. >> Or is your request really about a native 64bit variant? I'm afraid that >> then >> you're out of luck since I think that quite a bit of RXTX is not yet ready >> for 64 bit. >> Cheers, >> -- >> *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> ------------------------------------------------------------------------ >> *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On >> Behalf Of *Sandeep Kumar K >> *Sent:* Tuesday, August 05, 2008 7:19 PM >> *To:* rxtx at qbang.org >> *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so >> for Solaris 9 >> >> Hi, >> >> Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 >> bit machine. The librxtxSerial.so given in website is for Solaris 8. >> >> *-- >> Thanks & Regards >> >> Sandeep Kumar K >> Sr. Software Engineer >> Geneva Software Technologies >> Whitefield, Bangalore >> Mob : 9880193454* >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> From michael.erskine at ketech.com Wed Aug 6 01:39:28 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 6 Aug 2008 08:39:28 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Florian Manschwetus wrote: > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) Hi Florian, I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. Regards, Michael Erskine. From florianmanschwetus at gmx.de Wed Aug 6 02:53:16 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 06 Aug 2008 10:53:16 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Message-ID: <4899667C.6010706@gmx.de> Michael Erskine schrieb: > Florian Manschwetus wrote: >> Ok, sounds fine for the receiving problem. >> But why i have to wait after each byte when sending a command squence? >> (the for loop in send command) > > Hi Florian, > I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. > > Regards, > Michael Erskine. > correct with a terminal on the other end it works, my idea was that this basic baud has some influence. Could some one explain what it is for? Florian > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/c2b4fa84/attachment-0046.bin From rick_knight at rlknight.com Wed Aug 6 13:01:07 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:01:07 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F4F3.3020707@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > I have an application (Readerware) that uses RXTX with Javax to access the serial port. This used to work fine under previous Linux' and Java, but something has changed, I assume with Java itself , that is causing the application to fail with a link error. The application is not able to find librxtxSerialParallel.so. RXTX supplies librxtxSerial.so and librxtxParallel.so, but not librxtxSerialParallel.so. Where can I get librxtxSerialParallel.so, or do I need it? Is something else causing the lib to not be found? Thanks, Rick Knight From rick_knight at rlknight.com Wed Aug 6 13:17:55 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:17:55 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F8E3.5060400@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm > port support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have > just a ZIP with only the .class JAR file - no source or docs), has a > readme with these comments: > > /This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release. The 2.0.3 release itself is > no longer distributed. comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project. The RxTx project (http://www.rxtx.org > ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org ) was > opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > /I hope that is helpful! > > best regards > > Bruce Boyes > > ------- WWW.SYSTRONIX.COM ---------- > Real embedded Java and much more > +1-801-534-1017 Salt Lake City, USA > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Thanks for the reply. The developer of the app I'm trying to use (Readerware) has sent me a copy of the comm.api and I've copied the library (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar into the proper places. When I try to run the application, I get this error... Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: /usr/lib/libSolarisSerialParallel.so: /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not little-endian (Possible cause: endianness mismatch) Caught java.lang.UnsatisfiedLinkError: com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I while loading driver com.sun.comm.SolarisDriver Is there a way around this error? Thanks again, Rick Knight From jlar310 at gmail.com Wed Aug 6 13:37:42 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 14:37:42 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899F8E3.5060400@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > The developer of the app I'm trying to use (Readerware) has sent me a > copy of the comm.api and I've copied the library > (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar > into the proper places. When I try to run the application, I get this > error... > > Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: > /usr/lib/libSolarisSerialParallel.so: > /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not > little-endian (Possible cause: endianness mismatch) > Caught java.lang.UnsatisfiedLinkError: > com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I > > while loading driver com.sun.comm.SolarisDriver > > Is there a way around this error? What host OS are you running? From your original post it looks like 32 bit Linux. The libSolarisSerialParallel.so file is for Sun Solaris and will vary depending on the underlying hardware architecture as well. Sorry for the double post Rick, but I failed to send this to the list the first time... -- Jeff From rick_knight at rlknight.com Wed Aug 6 13:44:29 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:44:29 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> Message-ID: <4899FF1D.9030504@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: > > >> The developer of the app I'm trying to use (Readerware) has sent me a >> copy of the comm.api and I've copied the library >> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >> into the proper places. When I try to run the application, I get this >> error... >> >> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >> /usr/lib/libSolarisSerialParallel.so: >> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >> little-endian (Possible cause: endianness mismatch) >> Caught java.lang.UnsatisfiedLinkError: >> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >> >> while loading driver com.sun.comm.SolarisDriver >> >> Is there a way around this error? >> > > What host OS are you running? From your original post it looks like 32 > bit Linux. > > The libSolarisSerialParallel.so file is for Sun Solaris and will vary > depending on the underlying hardware architecture as well. > > I'm running Kubuntu Linux (debian based). It's 32 bit. Rick Knight From jlar310 at gmail.com Wed Aug 6 15:33:23 2008 From: jlar310 at gmail.com (Jeff) Date: Wed, 6 Aug 2008 16:33:23 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > I don't think Sun did binary libraries for Linux in the 2.0 version. Can someone with more historical experience than I confirm that? I recently tried to port a Comm API application from Solaris sparc to Linux x86 and likewise could not get my hands on the binary libraries. I eventually just re-wrote the code to use the gnu namespace packages and rxtx 2.1. What I don't understand is why your application vendor does not provide everything you need to run their software. FYI: I have librxtxParallel.so and librxtxSerial.so installed at JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is /usr/java/default which is actually a softlink to /usr/java/jre1.6.0_05. -- Jeff From defiantlew at yahoo.com.au Wed Aug 6 16:29:33 2008 From: defiantlew at yahoo.com.au (Lew L) Date: Thu, 7 Aug 2008 08:29:33 +1000 Subject: [Rxtx] Sun's Comm API Documentation References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> Message-ID: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> As a matter of interest is the Sun Comm API documentation available somewhere? I have tried the Sun site but it seems to have been removed. Unless I have missed the documentation for RXTX? I javadocced the RXTX source but information (to me) is minimal. Somewhere I got the impression that the Sun Comm API docs is, or was, compatible with RXTX, what is the best docs to use in conjuntion with RXTX and where may the be available? Cheers Lew From rick_knight at rlknight.com Wed Aug 6 17:18:33 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:18:33 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A3149.4050306@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff I'm not sure if I posted this here or not, but when I try to build RXTX from source I get this install error... make all-am make[1]: Entering directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' make[1]: Nothing to be done for `all-am'. make[1]: Leaving directory `/home/share/New Downloads/RXTX/rxtx-2.0-7pre2' libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 Can you tell me how to get past this error and get RXTX built and installed? Thanks, Rick From bboyes at systronix.com Wed Aug 6 17:40:12 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Wed, 06 Aug 2008 17:40:12 -0600 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: At 16:29 08/06/2008, Lew L wrote: >As a matter of interest is the Sun Comm API documentation available >somewhere? I have tried the Sun site but it seems to have been removed. It's in the file we have posted, link in prev email (sorry, in a huge hurry right now). Javadocs definitely there. >Unless I have missed the documentation for RXTX? I javadocced the RXTX >source but information (to me) is minimal. >Somewhere I got the impression that the Sun Comm API docs is, or was, >compatible with RXTX, what is the best docs to use in conjuntion with RXTX >and where may the be available? Yeah, this is one of my concerns/beefs. There is little documentation for RXTX and it isn't just the same as javaxcomm. I would be willing to help out writing docs for RXTX! Yes really... esp if we can fix the Bluetooth issues. best regards Bruce >Cheers >Lew > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx ------- WWW.SYSTRONIX.COM ---------- Real embedded Java and much more +1-801-534-1017 Salt Lake City, USA From rick_knight at rlknight.com Wed Aug 6 17:54:08 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 16:54:08 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: <489A39A0.2090309@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>> >>> >>> >>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>> copy of the comm.api and I've copied the library >>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>> into the proper places. When I try to run the application, I get this >>>> error... >>>> >>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>> /usr/lib/libSolarisSerialParallel.so: >>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>> little-endian (Possible cause: endianness mismatch) >>>> Caught java.lang.UnsatisfiedLinkError: >>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>> >>>> while loading driver com.sun.comm.SolarisDriver >>>> >>>> Is there a way around this error? >>>> >>>> >>> What host OS are you running? From your original post it looks like 32 >>> bit Linux. >>> >>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>> depending on the underlying hardware architecture as well. >>> >>> >>> >> I'm running Kubuntu Linux (debian based). It's 32 bit. >> >> > > I don't think Sun did binary libraries for Linux in the 2.0 version. > Can someone with more historical experience than I confirm that? > > I recently tried to port a Comm API application from Solaris sparc to > Linux x86 and likewise could not get my hands on the binary libraries. > I eventually just re-wrote the code to use the gnu namespace packages > and rxtx 2.1. > > What I don't understand is why your application vendor does not > provide everything you need to run their software. > > FYI: I have librxtxParallel.so and librxtxSerial.so installed at > JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is > /usr/java/default which is actually a softlink to > /usr/java/jre1.6.0_05. > > Jeff, I would like for my vendor to switch to rxtx 2.1. It would make things much easier for me. I'm not sure why he's still using the javax compatible code. He's a small operation. Re-writing the code to use gnu namespace sounds like a major overhaul. Was it? Thanks, Rick From tjarvi at qbang.org Wed Aug 6 21:35:12 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:35:12 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight wrote: >> >>> Jeff wrote: >>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >>>> >>>> >>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things > much easier for me. I'm not sure why he's still using the javax > compatible code. He's a small operation. Re-writing the code to use gnu > namespace sounds like a major overhaul. Was it? > Hi Jeff, The changes are fairly mechanical. Imports need to change and any explicite use of the namespace needs to change such as catching an exception. The following script was made for maintaining rxtx 2.0 but can apply to other needs. It is in the contrib dir with rxtx source. #!/bin/sh # Don't use! :) # # Sat, 03 May 2003 16:45:08 Modifications from J?rg Weule # Create a ed-cmd for the change of one pattern # case $1 in gnu) X=g/javax_comm/s+javax_comm+gnu_io+g ;; javax) X=g/gnu_io/s+gnu_io+javax_comm+g ;; *) echo;echo;echo From the top rxtx directory run;echo;echo -e \\t./ChangePackage.sh gnu;echo -e \\t\\tor;echo -e \\t./ChangePackage.sh javax;echo;echo; exit 0 ;; esac # # ed will be used to keep the owner and mode of the files unchanged. # We have run the ed-script for the characters '.' '/' as well. # "tr _ $D" do the change. # find . -type f -a -print | grep -v $0 | (while read F ; do ( echo $X; echo $X| tr _ /; echo $X| tr _ .; echo w; echo q ) | ed $F 2>&1 >/dev/null done ) # # Now we do little changes at the Makefiles. Hope that all we need. # find . -name Makefile\* -a -print | (while read F ; do cat < References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com><4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: On Thu, 7 Aug 2008, Lew L wrote: > As a matter of interest is the Sun Comm API documentation available > somewhere? I have tried the Sun site but it seems to have been removed. > > Unless I have missed the documentation for RXTX? I javadocced the RXTX > source but information (to me) is minimal. > Somewhere I got the impression that the Sun Comm API docs is, or was, > compatible with RXTX, what is the best docs to use in conjuntion with RXTX > and where may the be available? > Hi Lew, The documentation on Sun's website is accurate. The changes that are problematic in 3.0 are on the backside which rxtx used to plug into. http://java.sun.com/products/javacomm/reference/api/index.html CommPortIdentifier may have some minor differences (judging by the authors notes). -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Wed Aug 6 21:46:08 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 21:46:08 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <4899FF1D.9030504@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> Message-ID: On Wed, 6 Aug 2008, Rick Knight wrote: > Jeff wrote: >> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight wrote: >> >> >>> The developer of the app I'm trying to use (Readerware) has sent me a >>> copy of the comm.api and I've copied the library >>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>> into the proper places. When I try to run the application, I get this >>> error... >>> >>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>> /usr/lib/libSolarisSerialParallel.so: >>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>> little-endian (Possible cause: endianness mismatch) >>> Caught java.lang.UnsatisfiedLinkError: >>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>> >>> while loading driver com.sun.comm.SolarisDriver >>> >>> Is there a way around this error? >>> >> >> What host OS are you running? From your original post it looks like 32 >> bit Linux. >> >> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >> depending on the underlying hardware architecture as well. >> >> > > I'm running Kubuntu Linux (debian based). It's 32 bit. > If javax.comm.properties is properly installed and you are using a 2.0 version of Sun's commapi with rxtx 2.0, you should not see the library attempt to load libSolarisSerialParallel.so. Sun CommAPI 3.0 will not work with any version of rxtx as it is hard coded to use the shared library. See the INSTALL file with rxtx-2.0 source for more help with the properties file. -- Trent Jarvi tjarvi at qbang.org From jlar310 at gmail.com Thu Aug 7 06:32:06 2008 From: jlar310 at gmail.com (Jeff) Date: Thu, 7 Aug 2008 07:32:06 -0500 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <489A39A0.2090309@rlknight.com> References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > Jeff wrote: >> >> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >> wrote: >> >>> >>> Jeff wrote: >>> >>>> >>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>> wrote: >>>> >>>> >>>> >>>>> >>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>> copy of the comm.api and I've copied the library >>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>> into the proper places. When I try to run the application, I get this >>>>> error... >>>>> >>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>> /usr/lib/libSolarisSerialParallel.so: >>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>> little-endian (Possible cause: endianness mismatch) >>>>> Caught java.lang.UnsatisfiedLinkError: >>>>> >>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>> >>>>> while loading driver com.sun.comm.SolarisDriver >>>>> >>>>> Is there a way around this error? >>>>> >>>>> >>>> >>>> What host OS are you running? From your original post it looks like 32 >>>> bit Linux. >>>> >>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>> depending on the underlying hardware architecture as well. >>>> >>>> >>>> >>> >>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>> >>> >> >> I don't think Sun did binary libraries for Linux in the 2.0 version. >> Can someone with more historical experience than I confirm that? >> >> I recently tried to port a Comm API application from Solaris sparc to >> Linux x86 and likewise could not get my hands on the binary libraries. >> I eventually just re-wrote the code to use the gnu namespace packages >> and rxtx 2.1. >> >> What I don't understand is why your application vendor does not >> provide everything you need to run their software. >> >> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >> /usr/java/default which is actually a softlink to >> /usr/java/jre1.6.0_05. >> >> > > Jeff, > > I would like for my vendor to switch to rxtx 2.1. It would make things much > easier for me. I'm not sure why he's still using the javax compatible code. > He's a small operation. Re-writing the code to use gnu namespace sounds like > a major overhaul. Was it? I found it quite easy. In fact, in order to accommodate the transition, I actually separated all of the code that deals directly with the Comm API or RXTX into a helper class. The helper class was then coded to use reflection to determine which library was available and then instantiate the necessary objects. No direct imports of either library are used. The main application just needs to get it's hands on the IO streams and need not deal directly with the libraries. Other programs may not be so simple... But this doesn't really help you unless your vendor forks over the source code... -- Jeff From rick_knight at rlknight.com Thu Aug 7 09:47:12 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Thu, 07 Aug 2008 08:47:12 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <489A39A0.2090309@rlknight.com> Message-ID: <489B1900.10108@rlknight.com> Jeff wrote: > On Wed, Aug 6, 2008 at 6:54 PM, Rick Knight wrote: > >> Jeff wrote: >> >>> On Wed, Aug 6, 2008 at 2:44 PM, Rick Knight >>> wrote: >>> >>> >>>> Jeff wrote: >>>> >>>> >>>>> On Wed, Aug 6, 2008 at 2:17 PM, Rick Knight >>>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> The developer of the app I'm trying to use (Readerware) has sent me a >>>>>> copy of the comm.api and I've copied the library >>>>>> (libSolarisSerialParallel.so) and javax.comm.properties and comm.jar >>>>>> into the proper places. When I try to run the application, I get this >>>>>> error... >>>>>> >>>>>> Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: >>>>>> /usr/lib/libSolarisSerialParallel.so: >>>>>> /usr/lib/libSolarisSerialParallel.so: ELF file data encoding not >>>>>> little-endian (Possible cause: endianness mismatch) >>>>>> Caught java.lang.UnsatisfiedLinkError: >>>>>> >>>>>> com.sun.comm.SolarisDriver.readRegistrySerial(Ljava/util/Vector;Ljava/lang/String;)I >>>>>> >>>>>> while loading driver com.sun.comm.SolarisDriver >>>>>> >>>>>> Is there a way around this error? >>>>>> >>>>>> >>>>>> >>>>> What host OS are you running? From your original post it looks like 32 >>>>> bit Linux. >>>>> >>>>> The libSolarisSerialParallel.so file is for Sun Solaris and will vary >>>>> depending on the underlying hardware architecture as well. >>>>> >>>>> >>>>> >>>>> >>>> I'm running Kubuntu Linux (debian based). It's 32 bit. >>>> >>>> >>>> >>> I don't think Sun did binary libraries for Linux in the 2.0 version. >>> Can someone with more historical experience than I confirm that? >>> >>> I recently tried to port a Comm API application from Solaris sparc to >>> Linux x86 and likewise could not get my hands on the binary libraries. >>> I eventually just re-wrote the code to use the gnu namespace packages >>> and rxtx 2.1. >>> >>> What I don't understand is why your application vendor does not >>> provide everything you need to run their software. >>> >>> FYI: I have librxtxParallel.so and librxtxSerial.so installed at >>> JAVA_HOME/lib/i386 using Sun JRE on CentOS 4.6. JAVA_HOME is >>> /usr/java/default which is actually a softlink to >>> /usr/java/jre1.6.0_05. >>> >>> >>> >> Jeff, >> >> I would like for my vendor to switch to rxtx 2.1. It would make things much >> easier for me. I'm not sure why he's still using the javax compatible code. >> He's a small operation. Re-writing the code to use gnu namespace sounds like >> a major overhaul. Was it? >> > > I found it quite easy. In fact, in order to accommodate the > transition, I actually separated all of the code that deals directly > with the Comm API or RXTX into a helper class. The helper class was > then coded to use reflection to determine which library was available > and then instantiate the necessary objects. No direct imports of > either library are used. The main application just needs to get it's > hands on the IO streams and need not deal directly with the libraries. > Other programs may not be so simple... > > But this doesn't really help you unless your vendor forks over the > source code... > > Jeff, This may not help me directly, but I'm going to forward this thread to the vendor. I think he'll be open to making things work. Thanks again, Rick Knight From agusmunioz at gmail.com Thu Aug 7 16:39:51 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Thu, 7 Aug 2008 19:39:51 -0300 Subject: [Rxtx] How to send ack? Message-ID: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Hi, I'm still learning about serial communication and I have some doubts. I've got this question about how to do the following thing in rxtx. I have this hardware that connect to a PC using a serial port. These hardware receives data from a telephone line, proccess it, and then send it forward to the serial port. I've used a program named wincomm that shows what information is send it through the serial port and I have the nex behaviour: The hardware has a buffer where all data is stored, that cannot be sent it through the seria port. The program reads the first data send it by the hardware, and keep reading the same data always. There is a button in the application that says enable Ack, and when I click, then the hardware start to send all the stored information, and all the information is shown. I write a class, using rxtx that reads the serial port, and the same thing happens, it remains reading the same (first) data all the time. And I thing something like the enable Ack I'm missing. How can I do this enable Ack from my java code using rxtx? Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080807/e0a0f9a1/attachment-0044.html From ajmas at sympatico.ca Thu Aug 7 18:26:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Thu, 7 Aug 2008 20:26:41 -0400 Subject: [Rxtx] Sun's Comm API Documentation In-Reply-To: References: <48975796.4010600@rlknight.com> <4899F8E3.5060400@rlknight.com> <4899FF1D.9030504@rlknight.com> <000e01c8f813$e7f26a30$0100000a@ll35e1d2095fc2> Message-ID: <4BF42297-81E2-4BB8-A89F-1D43588379AE@sympatico.ca> On 6-Aug-08, at 19:40 , Bruce Boyes wrote: >> Unless I have missed the documentation for RXTX? I javadocced the >> RXTX >> source but information (to me) is minimal. >> Somewhere I got the impression that the Sun Comm API docs is, or was, >> compatible with RXTX, what is the best docs to use in conjuntion >> with RXTX >> and where may the be available? > > Yeah, this is one of my concerns/beefs. There is little documentation > for RXTX and it isn't just the same as javaxcomm. > > I would be willing to help out writing docs for RXTX! Yes really... > esp if we can fix the Bluetooth issues. If you want to contribute documentation then the best place to do that is the wiki. If there is anything missing or that could be improved on then please do so. If there are any points that you would like to see improved, for which you don't have the knowledge then ask on the mailing list for a volunteer. Andre From florianmanschwetus at gmx.de Fri Aug 8 03:04:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Fri, 08 Aug 2008 11:04:14 +0200 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> Message-ID: <489C0C0E.2020401@gmx.de> Agustin Mu?oz schrieb: > Hi, I'm still learning about serial communication and I have some > doubts. I've got this question about how to do the following thing in rxtx. > I have this hardware that connect to a PC using a serial port. These > hardware receives data from a telephone line, proccess it, and then send > it forward to the serial port. I've used a program named wincomm that > shows what information is send it through the serial port and I have the > nex behaviour: > > The hardware has a buffer where all data is stored, that cannot be sent > it through the seria port. > The program reads the first data send it by the hardware, and keep > reading the same data always. > There is a button in the application that says enable Ack, and when I > click, then the hardware start to send all the stored information, and > all the information is shown. > > I write a class, using rxtx that reads the serial port, and the same > thing happens, it remains reading the same (first) data all the time. > And I thing something like the enable Ack I'm missing. > How can I do this enable Ack from my java code using rxtx? Afaik, a look at man ascii reveals: Okt Dez Hex Char 006 6 06 ACK So, i hope this will do the job: send(6); florian > > Thanks in advance > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/5b4965f8/attachment-0044.bin From agusmunioz at gmail.com Fri Aug 8 16:31:00 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 19:31:00 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <489C0C0E.2020401@gmx.de> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> Message-ID: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Hi Florian, thanks for the answer. By send(6) you mean to get the port OutputStream and write a 6? I try that but it didn't work. Any suggestion? Thanks On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < florianmanschwetus at gmx.de> wrote: > Agustin Mu?oz schrieb: > > Hi, I'm still learning about serial communication and I have some doubts. >> I've got this question about how to do the following thing in rxtx. >> I have this hardware that connect to a PC using a serial port. These >> hardware receives data from a telephone line, proccess it, and then send it >> forward to the serial port. I've used a program named wincomm that shows >> what information is send it through the serial port and I have the nex >> behaviour: >> >> The hardware has a buffer where all data is stored, that cannot be sent >> it through the seria port. >> The program reads the first data send it by the hardware, and keep reading >> the same data always. >> There is a button in the application that says enable Ack, and when I >> click, then the hardware start to send all the stored information, and all >> the information is shown. >> >> I write a class, using rxtx that reads the serial port, and the same thing >> happens, it remains reading the same (first) data all the time. And I thing >> something like the enable Ack I'm missing. >> How can I do this enable Ack from my java code using rxtx? >> > Afaik, a look at man ascii reveals: > Okt Dez Hex Char > 006 6 06 ACK > So, i hope this will do the job: > send(6); > > florian > >> >> Thanks in advance >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/7f3fba42/attachment-0043.html From agusmunioz at gmail.com Fri Aug 8 18:39:27 2008 From: agusmunioz at gmail.com (=?ISO-8859-1?Q?Agustin_Mu=F1oz?=) Date: Fri, 8 Aug 2008 21:39:27 -0300 Subject: [Rxtx] How to send ack? In-Reply-To: <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> References: <988288430808071539n21bb9af8r97e3db57c5d7a993@mail.gmail.com> <489C0C0E.2020401@gmx.de> <988288430808081531k31042d0bic42d521ae1f05bd0@mail.gmail.com> Message-ID: <988288430808081739x7f9e7889id82591d5a9e2b4f6@mail.gmail.com> Ok, Florian, it works!! my problem was that I've been sending, through the OutputStream, the bytes of 6 as a string: out.write("6".getBytes()); but then I realized that you can write an int on an OuptuStream, so I tried that and It works: out.write(6); Thank you for the guidance!! On Fri, Aug 8, 2008 at 7:31 PM, Agustin Mu?oz wrote: > Hi Florian, thanks for the answer. By send(6) you mean to get the port > OutputStream and write a 6? > > I try that but it didn't work. > > Any suggestion? > > Thanks > > > On Fri, Aug 8, 2008 at 6:04 AM, Florian Manschwetus < > florianmanschwetus at gmx.de> wrote: > >> Agustin Mu?oz schrieb: >> >> Hi, I'm still learning about serial communication and I have some doubts. >>> I've got this question about how to do the following thing in rxtx. >>> I have this hardware that connect to a PC using a serial port. These >>> hardware receives data from a telephone line, proccess it, and then send it >>> forward to the serial port. I've used a program named wincomm that shows >>> what information is send it through the serial port and I have the nex >>> behaviour: >>> >>> The hardware has a buffer where all data is stored, that cannot be sent >>> it through the seria port. >>> The program reads the first data send it by the hardware, and keep >>> reading the same data always. >>> There is a button in the application that says enable Ack, and when I >>> click, then the hardware start to send all the stored information, and all >>> the information is shown. >>> >>> I write a class, using rxtx that reads the serial port, and the same >>> thing happens, it remains reading the same (first) data all the time. And I >>> thing something like the enable Ack I'm missing. >>> How can I do this enable Ack from my java code using rxtx? >>> >> Afaik, a look at man ascii reveals: >> Okt Dez Hex Char >> 006 6 06 ACK >> So, i hope this will do the job: >> send(6); >> >> florian >> >>> >>> Thanks in advance >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080808/b918ab3d/attachment-0043.html From florianmanschwetus at gmx.de Sat Aug 9 00:45:43 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Sat, 09 Aug 2008 08:45:43 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4899667C.6010706@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> Message-ID: <489D3D17.9090209@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >> Florian Manschwetus wrote: >>> Ok, sounds fine for the receiving problem. >>> But why i have to wait after each byte when sending a command squence? >>> (the for loop in send command) >> >> Hi Florian, >> I'd imagine you probably don't! You could send all bytes in one go and >> RXTX would send them. The problem is most probably the other end: >> perhaps it has a really small buffer, some non-standard UART, or a >> crazy timing issue. If you attach a terminal to your output and send >> all the bytes of a command in one go they should appear no problem. >> >> Regards, >> Michael Erskine. >> > correct with a terminal on the other end it works, my idea was that this > basic baud has some influence. Could some one explain what it is for? > > Florian To make it more clear, my problem is that i can't use: outputStream.write(byte[]); => Beamer doesn't understand the sequence. (mostly no answer when he answers then *001) when i use this construct instead: for (int i = 0; i < command.length; i++) { this.outputStream.write(command[i]); try { Thread.sleep(25); } catch (InterruptedException e) { // TODO Auto-generated catch block e.printStackTrace(); } } it works nearly reliable. So what could it be? This Basic Baud is what exactly? Florian -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080809/692304ee/attachment-0043.bin From tjarvi at qbang.org Sat Aug 9 16:37:19 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 9 Aug 2008 16:37:19 -0600 (MDT) Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489D3D17.9090209@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> <4899667C.6010706@gmx.de> <489D3D17.9090209@gmx.de> Message-ID: On Sat, 9 Aug 2008, Florian Manschwetus wrote: > Florian Manschwetus schrieb: >> Michael Erskine schrieb: >>> Florian Manschwetus wrote: >>>> Ok, sounds fine for the receiving problem. >>>> But why i have to wait after each byte when sending a command squence? >>>> (the for loop in send command) >>> >>> Hi Florian, >>> I'd imagine you probably don't! You could send all bytes in one go and >>> RXTX would send them. The problem is most probably the other end: perhaps >>> it has a really small buffer, some non-standard UART, or a crazy timing >>> issue. If you attach a terminal to your output and send all the bytes of a >>> command in one go they should appear no problem. >>> >>> Regards, >>> Michael Erskine. >>> >> correct with a terminal on the other end it works, my idea was that this >> basic baud has some influence. Could some one explain what it is for? >> >> Florian > To make it more clear, > my problem is that i can't use: > outputStream.write(byte[]); > => Beamer doesn't understand the sequence. (mostly no answer when he answers > then *001) > > when i use this construct instead: > > for (int i = 0; i < command.length; i++) { > this.outputStream.write(command[i]); > try { > Thread.sleep(25); > } catch (InterruptedException e) { > // TODO Auto-generated catch block > e.printStackTrace(); > } > } > > it works nearly reliable. > > So what could it be? This Basic Baud is what exactly? > I suspect you are using the 'moon protocol' and don't know it. RXTX enables this by default. The buffer on the other end is first in first out while reading. If the buffer is full, the bits are hand carried to the moon and burried. Then if the other side reads a couple bytes, two more bytes go into the buffer followed by more moon protocol. The resulting array of bytes the other side reads may appear to be scrambled until you go to the moon, get the bits and insert them in the right place. Flow control can prevent the default moon protocol and throttles the communiation by almost writing a byte at a time as need be. Hardware flow control is preferable but software flow control should also work. Read and write can appear to hang if the other side is not connected. This is why we don't enable them all the time. If you can't use flow control, you have to take care with the moon protocol and give the other side time to read. That is what your slower version of write is doing. -- Trent Jarvi tjarvi at qbang.org From rxtx at allenjb.me.uk Mon Aug 11 08:06:36 2008 From: rxtx at allenjb.me.uk (AllenJB) Date: Mon, 11 Aug 2008 15:06:36 +0100 Subject: [Rxtx] Disabling EV_RXFLAG Message-ID: <48A0476C.2090800@allenjb.me.uk> Hi all, I'm working with a device which does not use an EvtChar and need to disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an event mask of FD 01 00 00. The reference software I have uses FB 00 00 00. With the rxtx mask I get framing errors which I believe are caused when the EvtChar is received. Is there currently a way with rxtx (I've using rxtx from Java) to disable EV_RXFLAG? If not from Java, where would I start if I wanted to turn the EV_RXFLAG option off in the C code? I've had a grep of the rxtx source code, but I can't see where EV_RXFLAG is being set. Thanks in advance, AllenJB From tjarvi at qbang.org Mon Aug 11 14:17:27 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Aug 2008 14:17:27 -0600 (MDT) Subject: [Rxtx] Disabling EV_RXFLAG In-Reply-To: <48A0476C.2090800@allenjb.me.uk> References: <48A0476C.2090800@allenjb.me.uk> Message-ID: On Mon, 11 Aug 2008, AllenJB wrote: > Hi all, > > I'm working with a device which does not use an EvtChar and need to > disable EV_RXFLAG. According to my sniffer on WinXP, rxtx is using an > event mask of FD 01 00 00. The reference software I have uses FB 00 00 > 00. With the rxtx mask I get framing errors which I believe are caused > when the EvtChar is received. > > Is there currently a way with rxtx (I've using rxtx from Java) to > disable EV_RXFLAG? > > If not from Java, where would I start if I wanted to turn the EV_RXFLAG > option off in the C code? I've had a grep of the rxtx source code, but I > can't see where EV_RXFLAG is being set. > > Thanks in advance, > > AllenJB Hi Allen, I'd look at termios.c::tcsetattr() and termios.c::FillDCB() -- Trent Jarvi tjarvi at qbang.org From superdadusa at gmail.com Tue Aug 12 13:57:32 2008 From: superdadusa at gmail.com (John Choi) Date: Tue, 12 Aug 2008 13:57:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. Message-ID: Hi all, Just let you all know I just start to learn Java. I have download the serial comm package and the source code from open source communities.. I was able to verify with the given message string via serial monitor. when the given message string sends to the serial port then the character return added to the end of string by default if I use "Hello World" however if I changed to something else other than "Hello, World" there is no character return add to the end of string. I thing the library download from rxtx.org has implemented for the special strings. I can do like "login\n" in the string message to make character return but I don't want to add this individual custom character for each command return in every static message string I send, Can any who have done this might help me? Basically, something like this,, Write and add function to the program write a command, Reads the respond from a serial device.. Function handles multiple messages, Write: "com open" Read: Welcome to my world" expected Write: "admin" Read: Password?, expected Write: "admin" Read: you are successfully login terminal, expected. And I need to add a separate function handler handles a character return add to the each command above. If anyone can help this I can do the reset? Thank you in advance, John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0039.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SerialIO.java Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080812/f93e1cac/attachment-0039.pl From Steffen.DETTMER at ingenico.com Wed Aug 13 02:16:38 2008 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 13 Aug 2008 10:16:38 +0200 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: References: Message-ID: <20080813081638.GA25412@elberon.bln.de.ingenico.com> * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > I can do like "login\n" in the string message to make character > return but I don't want to add this individual custom character > for each command return in every static message string I send, and why not?! > Can any who have done this might help me? what's about with writing a small wrapper function adding the carriage return? However, this would be slow, because either you call write two times (very bad) or the string needs to be copied, \n appended and written (since you are using Java Performance probably isn't so critical). Personally I would write `"login\n"' and `username + "\n"' etc., because since it is part of the command it should be part of the command definition string. > Basically, something like this,, Write and add function to the program write > a command, Reads the respond from a serial device.. correctly reading a `line' is more difficult. If you cannot make assumptions about timeouts and/or you need to have low delay, you need to read byte wise. If you need to save CPU resources you might need to add some buffering layer that you can read byte-wise but that is reading blockwise with some small timeout (lets say for serial lines something around byte transmission time times three or so). > /* > * To change this template, choose Tools | Templates > * and open the template in the editor. > */ :) > package joliba; > > /** > * > * @author root > */ :) > // derived from SUN's examples in the javax.comm package > import java.io.*; > import java.util.*; > //import javax.comm.*; // for SUN's serial/parallel port libraries > import gnu.io.*; // for rxtxSerial library > > public class SerialIO implements Runnable, SerialPortEventListener { > static CommPortIdentifier portId; > static CommPortIdentifier saveportId; > static Enumeration portList; > InputStream inputStream; > SerialPort serialPort; > Thread readThread; You need a thread for your synchronous RPC-style protocol? > static String messageString = "Hello, world!"; > static OutputStream outputStream; > static boolean outputBufferEmptyFlag = false; > > public static void main(String[] args) { > boolean portFound = false; > String defaultPort; > > // determine the name of the serial port on several operating systems > String osname = System.getProperty("os.name","").toLowerCase(); > if ( osname.startsWith("windows") ) { > // windows > defaultPort = "COM1"; > } else if (osname.startsWith("linux")) { > // linux > defaultPort = "/dev/ttyS0"; > } else if ( osname.startsWith("mac") ) { > // mac > defaultPort = "????"; > } else { > System.out.println("Sorry, your operating system is not supported"); > return; > } Is such a construction recommended? Isn't there some abstraction (like COM1 working on any platform)? [...] > try { > // activate the OUTPUT_BUFFER_EMPTY notifier > serialPort.notifyOnOutputEmpty(true); > } catch (Exception e) { > System.out.println("Error setting event notification"); > System.out.println(e.toString()); > System.exit(-1); > } I doubt that -1 is defined, probably some 127 or so would be the result, maybe better simply `throw e'? > public void writetoport() { > System.out.println("Writing \""+messageString+"\" to "+serialPort.getName()); > try { > // write string to serial port > outputStream.write(messageString.getBytes()); > } catch (IOException e) {} > } maybe something like /** * Writes the given output string and an additional carriage * return to the current outputStream. */ public void writeStringToPort( /** The output string (without CR). */ String output ) throws IOException { String outputLine = output + "\n"; outputStream.write(outputLine.getBytes()); } ? > > public SerialIO() { > // initalize serial port > try { > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > } catch (PortInUseException e) {} if the port is in use, you continue? Wonder that this works in Java, I would assume serialPort beeing uninitialized which AFAIK is an error in Java. > try { > inputStream = serialPort.getInputStream(); > } catch (IOException e) {} > > try { > serialPort.addEventListener(this); > } catch (TooManyListenersException e) {} > > // activate the DATA_AVAILABLE notifier > serialPort.notifyOnDataAvailable(true); > > try { > // set port parameters > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > } catch (UnsupportedCommOperationException e) {} > > // start the read thread > readThread = new Thread(this); > readThread.start(); > > } I think in all those exception cases you can abort, because it is unlikely that ignoring those errors allow a successful continuation, so in this case maybe it would be better to add a throw clause to the method. > public void run() { > // first thing in the thread, we initialize the write operation > initwritetoport(); > try { > while (true) { > // write string to port, the serialEvent will read it > writetoport(); > Thread.sleep(1000); > } > } catch (InterruptedException e) {} > } Does this make sense? Your `SimpleReadApp' writes one and the same string each second? > public void serialEvent(SerialPortEvent event) { > switch (event.getEventType()) { > case SerialPortEvent.BI: > case SerialPortEvent.OE: > case SerialPortEvent.FE: > case SerialPortEvent.PE: > case SerialPortEvent.CD: > case SerialPortEvent.CTS: > case SerialPortEvent.DSR: > case SerialPortEvent.RI: > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > break; > case SerialPortEvent.DATA_AVAILABLE: > // we get here if data has been received > byte[] readBuffer = new byte[20]; > try { > // read data > while (inputStream.available() > 0) { > int numBytes = inputStream.read(readBuffer); > } > // print data > String result = new String(readBuffer); > System.out.println("Read: "+result); > } catch (IOException e) {} I doubt that this is correct. I would assume you will get a 20 bytes result always, if more bytes would be available they would be printed in a second line but if less bytes are read I'd assume that the buffer/result contains zero bytes from implicite readBuffer contents initialisation (zero is no string terminator in Java AFAIK). > break; > } > } > } oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From florianmanschwetus at gmx.de Wed Aug 13 06:09:31 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 13 Aug 2008 14:09:31 +0200 Subject: [Rxtx] someone has seen such errors? Message-ID: <48A2CEFB.90007@gmx.de> I mean my communication mostly works, but it is far from perfect could this be the reason? Florian Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios FAILED to set databits/stopbits/parity Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: ftdi_set_termios urb failed to set baudrate Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to clear flow control -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/949b9947/attachment-0039.bin From superdadusa at gmail.com Wed Aug 13 08:40:32 2008 From: superdadusa at gmail.com (John Choi) Date: Wed, 13 Aug 2008 08:40:32 -0600 Subject: [Rxtx] adding function in Java Serial command help. In-Reply-To: <20080813081638.GA25412@elberon.bln.de.ingenico.com> References: <20080813081638.GA25412@elberon.bln.de.ingenico.com> Message-ID: Thank you so much Steffen and I will try that suggestion. John On 8/13/08, Steffen DETTMER wrote: > > * John Choi wrote on Tue, Aug 12, 2008 at 13:57 -0600: > > I can do like "login\n" in the string message to make character > > return but I don't want to add this individual custom character > > for each command return in every static message string I send, > > and why not?! > > > Can any who have done this might help me? > > what's about with writing a small wrapper function adding the > carriage return? > However, this would be slow, because either you call write two > times (very bad) or the string needs to be copied, \n appended > and written (since you are using Java Performance probably isn't > so critical). > > Personally I would write `"login\n"' and `username + "\n"' etc., > because since it is part of the command it should be part of the > command definition string. > > > Basically, something like this,, Write and add function to the program > write > > a command, Reads the respond from a serial device.. > > correctly reading a `line' is more difficult. If you cannot make > assumptions about timeouts and/or you need to have low delay, you > need to read byte wise. If you need to save CPU resources you > might need to add some buffering layer that you can read > byte-wise but that is reading blockwise with some small timeout > (lets say for serial lines something around byte transmission > time times three or so). > > > /* > > * To change this template, choose Tools | Templates > > * and open the template in the editor. > > */ > > :) > > > package joliba; > > > > /** > > * > > * @author root > > */ > > :) > > > // derived from SUN's examples in the javax.comm package > > import java.io.*; > > import java.util.*; > > //import javax.comm.*; // for SUN's serial/parallel port libraries > > import gnu.io.*; // for rxtxSerial library > > > > public class SerialIO implements Runnable, SerialPortEventListener { > > static CommPortIdentifier portId; > > static CommPortIdentifier saveportId; > > static Enumeration portList; > > InputStream inputStream; > > SerialPort serialPort; > > Thread readThread; > > You need a thread for your synchronous RPC-style protocol? > > > static String messageString = "Hello, world!"; > > static OutputStream outputStream; > > static boolean outputBufferEmptyFlag = false; > > > > public static void main(String[] args) { > > boolean portFound = false; > > String defaultPort; > > > > // determine the name of the serial port on several operating > systems > > String osname = System.getProperty("os.name","").toLowerCase(); > > if ( osname.startsWith("windows") ) { > > // windows > > defaultPort = "COM1"; > > } else if (osname.startsWith("linux")) { > > // linux > > defaultPort = "/dev/ttyS0"; > > } else if ( osname.startsWith("mac") ) { > > // mac > > defaultPort = "????"; > > } else { > > System.out.println("Sorry, your operating system is not > supported"); > > return; > > } > > Is such a construction recommended? Isn't there some abstraction > (like COM1 working on any platform)? > > [...] > > try { > > // activate the OUTPUT_BUFFER_EMPTY notifier > > serialPort.notifyOnOutputEmpty(true); > > } catch (Exception e) { > > System.out.println("Error setting event notification"); > > System.out.println(e.toString()); > > System.exit(-1); > > } > > I doubt that -1 is defined, probably some 127 or so would be the > result, maybe better simply `throw e'? > > > public void writetoport() { > > System.out.println("Writing \""+messageString+"\" to > "+serialPort.getName()); > > try { > > // write string to serial port > > outputStream.write(messageString.getBytes()); > > } catch (IOException e) {} > > } > > maybe something like > > /** > * Writes the given output string and an additional carriage > * return to the current outputStream. > */ > public void > writeStringToPort( > /** The output string (without CR). */ > String output > ) throws IOException > { > String outputLine = output + "\n"; > outputStream.write(outputLine.getBytes()); > } > > ? > > > > > public SerialIO() { > > // initalize serial port > > try { > > serialPort = (SerialPort) portId.open("SimpleReadApp", 2000); > > } catch (PortInUseException e) {} > > if the port is in use, you continue? Wonder that this works in > Java, I would assume serialPort beeing uninitialized which AFAIK > is an error in Java. > > > try { > > inputStream = serialPort.getInputStream(); > > } catch (IOException e) {} > > > > try { > > serialPort.addEventListener(this); > > } catch (TooManyListenersException e) {} > > > > // activate the DATA_AVAILABLE notifier > > serialPort.notifyOnDataAvailable(true); > > > > try { > > // set port parameters > > serialPort.setSerialPortParams(9600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > } catch (UnsupportedCommOperationException e) {} > > > > // start the read thread > > readThread = new Thread(this); > > readThread.start(); > > > > } > > I think in all those exception cases you can abort, because it is > unlikely that ignoring those errors allow a successful > continuation, so in this case maybe it would be better to add a > throw clause to the method. > > > public void run() { > > // first thing in the thread, we initialize the write operation > > initwritetoport(); > > try { > > while (true) { > > // write string to port, the serialEvent will read it > > writetoport(); > > Thread.sleep(1000); > > } > > } catch (InterruptedException e) {} > > } > > Does this make sense? Your `SimpleReadApp' writes one and the > same string each second? > > > public void serialEvent(SerialPortEvent event) { > > switch (event.getEventType()) { > > case SerialPortEvent.BI: > > case SerialPortEvent.OE: > > case SerialPortEvent.FE: > > case SerialPortEvent.PE: > > case SerialPortEvent.CD: > > case SerialPortEvent.CTS: > > case SerialPortEvent.DSR: > > case SerialPortEvent.RI: > > case SerialPortEvent.OUTPUT_BUFFER_EMPTY: > > break; > > case SerialPortEvent.DATA_AVAILABLE: > > // we get here if data has been received > > byte[] readBuffer = new byte[20]; > > try { > > // read data > > while (inputStream.available() > 0) { > > int numBytes = inputStream.read(readBuffer); > > } > > // print data > > String result = new String(readBuffer); > > System.out.println("Read: "+result); > > } catch (IOException e) {} > > I doubt that this is correct. I would assume you will get a 20 > bytes result always, if more bytes would be available they would > be printed in a second line but if less bytes are read I'd assume > that the buffer/result contains zero bytes from implicite > readBuffer contents initialisation (zero is no string terminator > in Java AFAIK). > > > break; > > } > > } > > } > > oki, > > Steffen > > About Ingenico Throughout the world businesses rely on Ingenico for secure > and expedient electronic transaction acceptance. Ingenico products leverage > proven technology, established standards and unparalleled ergonomics to > provide optimal reliability, versatility and usability. This comprehensive > range of products is complemented by a global array of services and > partnerships, enabling businesses in a number of vertical sectors to accept > transactions anywhere their business takes them. > www.ingenico.com This message may contain confidential and/or privileged > information. If you are not the addressee or authorized to receive this for > the addressee, you must not use, copy, disclose or take any action based on > this message or any information herein. If you have received this message in > error, please advise the sender immediately by reply e-mail and delete this > message. Thank you for your cooperation. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080813/73c4135c/attachment-0038.html From ajmas at sympatico.ca Sat Aug 16 07:15:41 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 09:15:41 -0400 Subject: [Rxtx] someone has seen such errors? In-Reply-To: <48A2CEFB.90007@gmx.de> References: <48A2CEFB.90007@gmx.de> Message-ID: <43B5E8DA-1D93-4D90-809B-AAF35FF724C5@sympatico.ca> On 13-Aug-08, at 08:09 , Florian Manschwetus wrote: > I mean my communication mostly works, but it is far from perfect > could this be the reason? > > Florian > > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios FAILED to set databits/stopbits/parity > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: > ftdi_set_termios urb failed to set baudrate > Aug 13 13:17:10 hdwall drivers/usb/serial/ftdi_sio.c: urb failed to > clear flow control Judging by the error messages this looks related to the driver you are using. Do a search for the following string with you favourite search engine, it should turn up a few hits: ftdi_set_termios FAILED to set databits/stopbits/parity Andre From ajmas at sympatico.ca Sat Aug 16 19:12:04 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 21:12:04 -0400 Subject: [Rxtx] Using SerialPortEvent? Message-ID: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Hi, Could someone tell me how I should be using the SerialPortEvent? Am I meant to be waiting for data and then simply reading from the inputstream? If this is the case why no just block on an inputstream read? Andr? From tjarvi at qbang.org Sat Aug 16 19:41:13 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 16 Aug 2008 19:41:13 -0600 (MDT) Subject: [Rxtx] Using SerialPortEvent? In-Reply-To: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> References: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Message-ID: On Sat, 16 Aug 2008, Andre-John Mas wrote: > Hi, > > Could someone tell me how I should be using the SerialPortEvent? Am I > meant to be waiting for data and then simply reading from the > inputstream? If this is the case why no just block on an inputstream > read? > Polling for data is fine also. It really depends upon what you are trying to do. For instance, if you require x bytes before reading, you can start polling after data is available. If you read on the same thread as your GUI and are waiting for data in a read, the results may be less than desirable. Java programming is 'usually' event driven rather than polling based. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Sat Aug 16 20:10:39 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 16 Aug 2008 22:10:39 -0400 Subject: [Rxtx] Using SerialPortEvent? In-Reply-To: References: <6FD3589D-94DB-4529-ADBA-D77867BACAD7@sympatico.ca> Message-ID: <3E495D4C-BB28-4845-A6AB-984C9A826BDF@sympatico.ca> On 16-Aug-08, at 21:41 , Trent Jarvi wrote: > On Sat, 16 Aug 2008, Andre-John Mas wrote: > >> Hi, >> >> Could someone tell me how I should be using the SerialPortEvent? Am I >> meant to be waiting for data and then simply reading from the >> inputstream? If this is the case why no just block on an inputstream >> read? >> > > Polling for data is fine also. It really depends upon what you are > trying to do. For instance, if you require x bytes before reading, > you can start polling after data is available. If you read on the > same thread as your GUI and are waiting for data in a read, the > results may be less than desirable. > > Java programming is 'usually' event driven rather than polling based. Sounds good. I thought I would use this opportunity to provide a event based version of the TwoWaySerialComm example. Could you just validate it before I add it to the Wiki: package ajmas74.experimental; import gnu.io.CommPort; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; import gnu.io.SerialPortEvent; import gnu.io.SerialPortEventListener; import java.io.IOException; import java.io.InputStream; import java.io.OutputStream; /** * This version of the TwoWaySerialComm example makes use of the * SerialPortEventListener to avoid polling. * * @author ajmas * */ public class TwoWaySerialComm { public TwoWaySerialComm() { super(); } void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { CommPort commPort = portIdentifier.open(this.getClass().getName(),2000); if ( commPort instanceof SerialPort ) { SerialPort serialPort = (SerialPort) commPort; serialPort .setSerialPortParams (57600 ,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); (new Thread(new SerialWriter(out))).start(); serialPort.addEventListener(new SerialReader(in)); } else { System.out.println("Error: Only serial ports are handled by this example."); } } } /** * Handles the input coming from the serial port. A new line character * is treated as the end of a block in this example. */ public static class SerialReader implements SerialPortEventListener { private InputStream in; private byte[] buffer = new byte[1024]; public SerialReader ( InputStream in ) { this.in = in; } public void serialEvent(SerialPortEvent arg0) { int data; try { int len = 0; while ( ( data = in.read()) > -1 ) { if ( data != '\n' ) { break; } buffer[len++] = (byte) data; } System.out.print(new String(buffer,0,len)); } catch ( IOException e ) { e.printStackTrace(); System.exit(-1); } } } /** */ public static class SerialWriter implements Runnable { OutputStream out; public SerialWriter ( OutputStream out ) { this.out = out; } public void run () { try { int c = 0; while ( ( c = System.in.read()) > -1 ) { this.out.write(c); } } catch ( IOException e ) { e.printStackTrace(); System.exit(-1); } } } public static void main ( String[] args ) { try { (new TwoWaySerialComm()).connect("COM3"); } catch ( Exception e ) { e.printStackTrace(); } } } From lfarkas at lfarkas.org Tue Aug 19 07:32:59 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Tue, 19 Aug 2008 15:32:59 +0200 Subject: [Rxtx] JNI or CNI Message-ID: <48AACB8B.9060606@lfarkas.org> hi, what is the current recommended way to rxtx on linux JNI or it's better to use CNI? is the CNI version fully functional and the same level as the JNI? i currently try to make a rhel/centos/fedora rpm for rxtx but has many problems with the standard dir structure. yours. -- Levente "Si vis pacem para bellum!" From lfarkas at lfarkas.org Tue Aug 19 08:47:34 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Tue, 19 Aug 2008 16:47:34 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel Message-ID: <48AADD06.7040809@lfarkas.org> hi, newer or not so newer linux kernel do not contain the UTS_RELEASE so the current rxtx is not compile on the latest kernels. even if it's commented out in the cvs configure there are other places. i attcahed a patch which fix it (or at least doesn't cause error at non-debug build). ps. is there any plan to the new 2.1-8 release in the near future? there are many changes (at least the license change in all file and in this case create a diff is very difficult)? the latest release more then 2 years old:-( -- Levente "Si vis pacem para bellum!" -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rxtx-2.1-uts.patch Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20080819/ab5d38ac/attachment-0032.pl From ajmas at sympatico.ca Tue Aug 19 16:21:53 2008 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 19 Aug 2008 18:21:53 -0400 Subject: [Rxtx] Event based example Message-ID: <24735BFB-B088-4B84-8173-FE98DF63B12F@sympatico.ca> Hi, I have just posted an example of using SerialPortEventListener in the Wiki: http://rxtx.qbang.org/wiki/index.php/Event_Based_Two_Way_Communication If you see any issues please could you let me know, or makes the changes. Andre From Martin.Oberhuber at windriver.com Fri Aug 22 04:02:24 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Fri, 22 Aug 2008 12:02:24 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <48AADD06.7040809@lfarkas.org> References: <48AADD06.7040809@lfarkas.org> Message-ID: <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> Farkas, there are indeed efforts to get a new RXTX release out the door. Your experience as a package maintainer would likely be helpful during these efforts, since I'd think it makes sense to keep the patches minimal that you must make to have the source compile in your environment. What are the things that you find problematic, apart from the UTS thing that you have mentioned before? What is the timing that you have in mind for your package? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > On Behalf Of Farkas Levente > Sent: Tuesday, August 19, 2008 4:48 PM > To: rxtx at qbang.org > Subject: [Rxtx] UTS_RELEASE not defined in newer kernel > > hi, > newer or not so newer linux kernel do not contain the > UTS_RELEASE so the > current rxtx is not compile on the latest kernels. even if it's > commented out in the cvs configure there are other places. > i attcahed a patch which fix it (or at least doesn't cause error at > non-debug build). > > ps. is there any plan to the new 2.1-8 release in the near > future? there > are many changes (at least the license change in all file and in this > case create a diff is very difficult)? the latest release more then 2 > years old:-( > > -- > Levente "Si vis pacem para bellum!" > From lfarkas at lfarkas.org Fri Aug 22 04:36:26 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Fri, 22 Aug 2008 12:36:26 +0200 Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> References: <48AADD06.7040809@lfarkas.org> <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> Message-ID: <48AE96AA.6090505@lfarkas.org> hi, the packages already build for fedora-9 and centos-5 and here: http://www.lfarkas.org/linux/packages/ what i've to patch, the UTS, the configure script, but it's already fixed in the cvs (in another way) and the loadlibrary. the reasons for last one can be found here: https://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_files_that_use_JNI after we test it i'd like to add these packages to fedora and epel main repository (that's why it's be useful a new release after 2 years:-) imho versions are cheap and why not just release 2.1-8? the real code changes are minimal and if something critical bug found still can release 2.1-9:-) ps. and would be better to use simple number for version like 2.1-7 rather then 2.1-7v2. Oberhuber, Martin wrote: > Farkas, > > there are indeed efforts to get a new RXTX release out the > door. Your experience as a package maintainer would likely > be helpful during these efforts, since I'd think it makes > sense to keep the patches minimal that you must make to > have the source compile in your environment. > > What are the things that you find problematic, apart from > the UTS thing that you have mentioned before? > > What is the timing that you have in mind for your package? > > Cheers, > -- > Martin Oberhuber, Senior Member of Technical Staff, Wind River > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > >> -----Original Message----- >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >> On Behalf Of Farkas Levente >> Sent: Tuesday, August 19, 2008 4:48 PM >> To: rxtx at qbang.org >> Subject: [Rxtx] UTS_RELEASE not defined in newer kernel >> >> hi, >> newer or not so newer linux kernel do not contain the >> UTS_RELEASE so the >> current rxtx is not compile on the latest kernels. even if it's >> commented out in the cvs configure there are other places. >> i attcahed a patch which fix it (or at least doesn't cause error at >> non-debug build). >> >> ps. is there any plan to the new 2.1-8 release in the near >> future? there >> are many changes (at least the license change in all file and in this >> case create a diff is very difficult)? the latest release more then 2 >> years old:-( >> >> -- >> Levente "Si vis pacem para bellum!" >> -- Levente "Si vis pacem para bellum!" From tjarvi at qbang.org Fri Aug 22 18:50:32 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Aug 2008 18:50:32 -0600 (MDT) Subject: [Rxtx] UTS_RELEASE not defined in newer kernel In-Reply-To: <48AE96AA.6090505@lfarkas.org> References: <48AADD06.7040809@lfarkas.org> <460801A4097E3D4CA04CC64EE64858480730F0DD@ism-mail03.corp.ad.wrs.com> <48AE96AA.6090505@lfarkas.org> Message-ID: Hi Farkas, The v2 was simply the second build - no code changes. We are comming out with a new release shortly. I would encourage working with distros as you are. The building of rxtx turns out to be a bottle neck in quick releases. We do want stable releases that work for a year or more but I would have no problems with quicker cycles on developing work. I would have no problem working with someone that did builds that receive less testing more often but they do have to come out for multiple platforms from this end. Thanks for the links. On Fri, 22 Aug 2008, Farkas Levente wrote: > hi, > the packages already build for fedora-9 and centos-5 and here: > http://www.lfarkas.org/linux/packages/ > what i've to patch, the UTS, the configure script, but it's already > fixed in the cvs (in another way) and the loadlibrary. the reasons for > last one can be found here: > https://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_files_that_use_JNI > after we test it i'd like to add these packages to fedora and epel main > repository (that's why it's be useful a new release after 2 years:-) > imho versions are cheap and why not just release 2.1-8? the real code > changes are minimal and if something critical bug found still can > release 2.1-9:-) > > ps. and would be better to use simple number for version like 2.1-7 > rather then 2.1-7v2. > > Oberhuber, Martin wrote: >> Farkas, >> >> there are indeed efforts to get a new RXTX release out the >> door. Your experience as a package maintainer would likely >> be helpful during these efforts, since I'd think it makes >> sense to keep the patches minimal that you must make to >> have the source compile in your environment. >> >> What are the things that you find problematic, apart from >> the UTS thing that you have mentioned before? >> >> What is the timing that you have in mind for your package? >> >> Cheers, >> -- >> Martin Oberhuber, Senior Member of Technical Staff, Wind River >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> >> >>> -----Original Message----- >>> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >>> On Behalf Of Farkas Levente >>> Sent: Tuesday, August 19, 2008 4:48 PM >>> To: rxtx at qbang.org >>> Subject: [Rxtx] UTS_RELEASE not defined in newer kernel >>> >>> hi, >>> newer or not so newer linux kernel do not contain the >>> UTS_RELEASE so the >>> current rxtx is not compile on the latest kernels. even if it's >>> commented out in the cvs configure there are other places. >>> i attcahed a patch which fix it (or at least doesn't cause error at >>> non-debug build). >>> >>> ps. is there any plan to the new 2.1-8 release in the near >>> future? there >>> are many changes (at least the license change in all file and in this >>> case create a diff is very difficult)? the latest release more then 2 >>> years old:-( >>> >>> -- >>> Levente "Si vis pacem para bellum!" >>> > > > From andy at triera.net Sat Aug 23 15:17:44 2008 From: andy at triera.net (Andy Rozman) Date: Sat, 23 Aug 2008 21:17:44 +0000 Subject: [Rxtx] port not identified on FreeBSD In-Reply-To: References: Message-ID: <48B07E78.2030306@triera.net> Hi ! I have one small problem... I have started using FreeBSD in last few days and I have come accross a problem with rxtx on FreeBSD. I am using usb-to-serial converter, which is identified under FreeBSD without problem as ucom0, and creates link under /dev called ttyU0, which is correct way to be done under FreeBSD (if device would be unidentified it would be called ugen0 - as usb generic). Problem is that I say to rxtx to get my all serial ports this one is not among them. Which names are permissable under linux-like implementations? Which will be accepted as serial ports? Andy From tjarvi at qbang.org Sat Aug 23 13:57:45 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 23 Aug 2008 13:57:45 -0600 (MDT) Subject: [Rxtx] port not identified on FreeBSD In-Reply-To: <48B07E78.2030306@triera.net> References: <48B07E78.2030306@triera.net> Message-ID: On Sat, 23 Aug 2008, Andy Rozman wrote: > Hi ! > > I have one small problem... I have started using FreeBSD in last few > days and I have come accross a problem with rxtx on FreeBSD. > > I am using usb-to-serial converter, which is identified under FreeBSD > without problem as ucom0, and creates link under /dev called > ttyU0, which is correct way to be done under FreeBSD (if device would be > unidentified it would be called ugen0 - as usb generic). Problem is that > I say to rxtx to get my all serial ports this one is not among them. > Which names are permissable under linux-like implementations? Which will > be accepted as serial ports? > > Andy > Thanks Andy! We will add ttyU* to FreeBSD. For now you can use properties to enable the port. http://rxtx.qbang.org/wiki/index.php/Trouble_shooting#How_does_rxtx_detect_ports.3F__Can_I_override_it.3F The fix: diff -u -r1.16.2.59 RXTXCommDriver.java --- RXTXCommDriver.java 18 Nov 2007 22:32:41 -0000 1.16.2.59 +++ RXTXCommDriver.java 23 Aug 2008 19:55:25 -0000 @@ -644,6 +644,7 @@ { String[] Temp = { "ttyd", //general purpose serial ports + "ttyU", //general purpose USB serial ports "cuaa", //dialout serial ports "ttyA", //Specialix SI/XIO dialin ports "cuaA", //Specialix SI/XIO dialout ports -- Trent Jarvi tjarvi at qbang.org From rick_knight at rlknight.com Mon Aug 4 13:25:10 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Mon, 04 Aug 2008 12:25:10 -0700 Subject: [Rxtx] Sun's Comm API? Message-ID: <48975796.4010600@rlknight.com> I have an application that requires the javax compatible version of RXTX and Sun's comm api. I've been able to download and extract the version of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api anywhere. Can someone tell me where I can find it? Or maybe send me a copy? Also, when I try to build RXTX, configure and make complete successfully but make install failes with this error libtool: install: `i686-pc-linux-gnu' must be an absolute directory name Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 I've never come accross this error before. How can I get past it? Thanks, Rick From bboyes at systronix.com Mon Aug 4 19:10:01 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:10:01 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48975796.4010600@rlknight.com> References: <48975796.4010600@rlknight.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/cb9c6167/attachment-0048.html From bboyes at systronix.com Mon Aug 4 19:12:37 2008 From: bboyes at systronix.com (Bruce Boyes) Date: Mon, 04 Aug 2008 19:12:37 -0600 Subject: [Rxtx] Towards an RXTX release - CSR BT/USB chipset In-Reply-To: <488FB7E7.8000802@gmail.com> References: <460801A4097E3D4CA04CC64EE648584806C56CF0@ism-mail03.corp.ad.wrs.com> <13557-75390@sneakemail.com> <20980-23424@sneakemail.com> <488FB7E7.8000802@gmail.com> Message-ID: An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080804/52236088/attachment-0048.html From tjarvi at qbang.org Mon Aug 4 19:42:21 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 19:42:21 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: On Mon, 4 Aug 2008, Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: > I have an application that requires the javax compatible > version of RXTX > and Sun's comm api. I've been able to download and extract > the version > of RXTX that I need (2.0-7pre2) but I can't find Sun's camm > api > anywhere. Can someone tell me where I can find it? Or maybe > send me a > > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has to use RXTX to get comm port > support. > > The version we use is 2.0 from 11/15/1998. I have posted it on our > website, which is within the terms of the license agreement contained > therein (as I understand it). > > The last version of javaxcomm for Windows, 2.0.3, (for which I have just > a ZIP with only the .class JAR file - no source or docs), has a readme > with these comments: > > This distribution contains the comm.jar file original part > of the COMMAPI 2.0.3 release.? The 2.0.3 release itself is > no longer distributed.? comm.jar, which contains the comm > API java class files (eg. Sun's binary implementation of the > interface classes), is being made available, unsupported, > with no obligation to fix bugs, at the request of the RXTX > project.? The RxTx project (http://www.rxtx.org ), uses the > comm.jar class files, but provides their own native library > components to provide support for other platforms. > > The 2.0.3 comm.jar is being provided in this way because > as of COMMAPI 3.x, the java binary implementation forked and > became incompatible with the RxTx project's native code. > Due to the lack of a clear business case, and to resource > constraints, no additional resources are being > provided to provide an alternative engineering solution > at the time of writing. > > RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: > > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org) was opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support.? Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins.? Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. > ? > Since there are now various ways serial ports can be implemented > and accessed, modular comm. port JNI native libraries would be > of benefit insofar as removing the burden of over-generalization > from any single native component, or inversely, by relieving the > implicit constraint that comm. drivers be accessed only via a > monolithic mechanism, such as the UNIX vnode interface. > > paul.klissner at sun.com > 6/10/06 > > I hope that is helpful! > It would be nice to work with Sun to resolve those longstanding issues. But it may not be practical unless the process goes as fast and painless as the grandfathering of commapi did. Another option may be the old kaffe extensions that moved to gnu classpathx. These don't have the native libraries but should provide the 2.0 interface and the javax.comm.properties mechansim for SPI. http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx -- Trent Jarvi tjarvi at qbang.org From jredman at ergotech.com Mon Aug 4 20:23:57 2008 From: jredman at ergotech.com (Jim Redman) Date: Mon, 04 Aug 2008 20:23:57 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4897B9BD.5070809@ergotech.com> Has there been any work/would it be possible, to layer a javacomm look-alike on top of the GNU code? The goal is not to move the javax code forward, but to emulate the "legacy" javax packages for people who still need this. Jim Trent Jarvi wrote: > On Mon, 4 Aug 2008, Bruce Boyes wrote: > >> At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible >> version of RXTX >> and Sun's comm api. I've been able to download and extract >> the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm >> api >> anywhere. Can someone tell me where I can find it? Or maybe >> send me a >> >> >> javaxcomm has had a sort of on-again off-again history. The windoze >> version has been languishing for years (literally) but there are newer >> versions for other OS's. >> >> We try to keep links on one of our help pages current: >> http://www.practicalembeddedjava.com/tools/javatools_list.html >> which gets you to here: >> http://java.sun.com/products/javacomm/ >> where it says in fact they no longer even support Windows and Mac: >> "Implementations of the API are currently available for Solaris SPARC, >> Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so >> someone could support it. But I guess that's part of the reason RXTX >> exists! >> >> So one of Sun's own products, SunSPOT, has to use RXTX to get comm port >> support. >> >> The version we use is 2.0 from 11/15/1998. I have posted it on our >> website, which is within the terms of the license agreement contained >> therein (as I understand it). >> >> The last version of javaxcomm for Windows, 2.0.3, (for which I have just >> a ZIP with only the .class JAR file - no source or docs), has a readme >> with these comments: >> >> This distribution contains the comm.jar file original part >> of the COMMAPI 2.0.3 release. The 2.0.3 release itself is >> no longer distributed. comm.jar, which contains the comm >> API java class files (eg. Sun's binary implementation of the >> interface classes), is being made available, unsupported, >> with no obligation to fix bugs, at the request of the RXTX >> project. The RxTx project (http://www.rxtx.org ), uses the >> comm.jar class files, but provides their own native library >> components to provide support for other platforms. >> >> The 2.0.3 comm.jar is being provided in this way because >> as of COMMAPI 3.x, the java binary implementation forked and >> became incompatible with the RxTx project's native code. >> Due to the lack of a clear business case, and to resource >> constraints, no additional resources are being >> provided to provide an alternative engineering solution >> at the time of writing. >> >> RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: >> >> Ultimately the COMMAPI would be better served if a Java >> Community Process JSR (http://www.jcp.org) was opened and >> the COMMAPI was rearchitected to provide a more pluggable >> framework to improve cross-platform support. Such an >> architecture would embody a better defined and better >> documented SPI interface, including a way for comm. ports >> to be revealed to the client application through the API >> via platform-aware plugins. Similarly, native code used >> to access comm port in general could be handled more >> flexibly using a plugin model, whereby on any platform, >> multiple native modules could be in use simultaneously. >> >> Since there are now various ways serial ports can be implemented >> and accessed, modular comm. port JNI native libraries would be >> of benefit insofar as removing the burden of over-generalization >> from any single native component, or inversely, by relieving the >> implicit constraint that comm. drivers be accessed only via a >> monolithic mechanism, such as the UNIX vnode interface. >> >> paul.klissner at sun.com >> 6/10/06 >> >> I hope that is helpful! >> > > It would be nice to work with Sun to resolve those longstanding issues. > But it may not be practical unless the process goes as fast and painless > as the grandfathering of commapi did. > > Another option may be the old kaffe extensions that moved to gnu > classpathx. These don't have the native libraries but should provide > the 2.0 interface and the javax.comm.properties mechansim for SPI. > > http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx > > -- > Trent Jarvi > tjarvi at qbang.org > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Mon Aug 4 21:09:15 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Aug 2008 21:09:15 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? Message-ID: Hi Jim, I will not step into the javax.comm namespace without Sun's explicite permission. I fully understand the pain point you are trying to address. In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm Linux) - which remains an integral part of rxtx. At the time it was a win for Sun and rxtx. The Sun commapi license is/was fairly clear that rxtx should not step into that namespace. It made sense as Sun was active in that space and rxtx may go into another namespace - it was an experiment in working with Sun. This may sound silly looking at something that happened almost 10 years ago. In a community of respect which Sun helped create, there is no question about what to do. I hope eventually Sun will step up and do a right thing too. I agree that this is hurting the API more than helping it. There are also questions about how to replace the API in the long term which includes HID support which isn't going well so far. Others that can't even look at Sun's javax.comm today and can look at Kaffe's contribution to classpathx can easily work around such restrictions. On Mon, 4 Aug 2008, Jim Redman wrote: > Has there been any work/would it be possible, to layer a javacomm > look-alike on top of the GNU code? > > The goal is not to move the javax code forward, but to emulate the > "legacy" javax packages for people who still need this. > > Jim > > Trent Jarvi wrote: >> >> It would be nice to work with Sun to resolve those longstanding issues. >> But it may not be practical unless the process goes as fast and painless >> as the grandfathering of commapi did. >> >> Another option may be the old kaffe extensions that moved to gnu >> classpathx. These don't have the native libraries but should provide >> the 2.0 interface and the javax.comm.properties mechansim for SPI. >> >> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From florianmanschwetus at gmx.de Tue Aug 5 05:04:46 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 13:04:46 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: References: <48971C1F.9020806@gmx.de> Message-ID: <489833CE.1040801@gmx.de> Just look at sendCommand in this method I have to place a Thread.sleep(20) after each byte send to get working. Even the event based receive doesn't work fine but this could be may stupidness. The specifikation document (it is on the last pages of the manual) for the beamer could be found on: http://www.optoma.co.uk/support.aspx Florian Manschwetus Trent Jarvi schrieb: > > Hi Florian > > Sorry for the top post in advance. I worry you may not see my answer > under all your code :) > > I have not received this email before. This is 500k of code which I > don't have time to read. I can spend about 5 min on each hobby email > and still get to work in the morning. I have a couple suggestions for > how to get an answer. > > First, cut out your comments and extra code so you can demonstrate the > question (I might even glance and see what is wrong then). Don't go for > a working final product. Isolate the problem using a simple program and > then ask with that as an example. If I did what you just did, I'd have > to post 3/4 of a million lines of code :) > > Second, join the rxtx mail-list and ask there. This will give you 100x > more eyes. I'll also read and try to follow. > > -- > taj > > > > On Mon, 4 Aug 2008, Florian Manschwetus wrote: > >> It could be that my university account is blocked by filters so >> resending from here. >> >> >> Topic is to control Optoma HD80 beamer using rs232 serial chat. >> This code is able to detect power state and switch the beamer on / off. >> connected is the beamer using a digitus usb 2.0 serial adapter with an >> FT232 USB-Serial adapter the systems architecture is amd64. >> >> Please take a look in the sendCommand routine i have to place theire >> those Thread.sleep to get it working. >> Now the question is this correct or is there a better way to get this >> working correctly? >> >> In the javadoc coming with the install i found this: >> setBaudBase >> >> public boolean setBaudBase(int BaudBase) >> throws UnsupportedCommOperationException, >> java.io.IOException >> >> Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 >> before using. >> >> could this explain the error? >> I attached my java source and the protocol description for the beamer >> (available on vendor website). >> >> thx, >> Florian Manschwetus >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: TestRS232.java Type: text/x-java Size: 9143 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0096.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/215161c5/attachment-0097.bin From michael.erskine at ketech.com Tue Aug 5 05:53:49 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Tue, 5 Aug 2008 12:53:49 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <489833CE.1040801@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> > Just look at sendCommand in this method I have to place a > Thread.sleep(20) after each byte send to get working. Even the event > based receive doesn't work fine but this could be may stupidness. Hi Florian, Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. Regards, Michael Erskine. From florianmanschwetus at gmx.de Tue Aug 5 07:28:15 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:28:15 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> Message-ID: <4898556F.8000208@gmx.de> Michael Erskine schrieb: >> Just look at sendCommand in this method I have to place a >> Thread.sleep(20) after each byte send to get working. Even the event >> based receive doesn't work fine but this could be may stupidness. > > Hi Florian, > > Yes, naturally you'll have to wait for a response from the other end. Why not wait for notification from the event thread perhaps using a BlockingDeque rather than your LinkedList. Generally I try to decouple all input and output streams: in your case your application is operating synchronously like the "expect" program (http://expect.nist.gov/) so waits (or timeouts) will need to be factored in. > > Regards, > Michael Erskine. > Ok, sounds fine for the receiving problem. But why i have to wait after each byte when sending a command squence? (the for loop in send command) Florian > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/284f350c/attachment-0047.bin From florianmanschwetus at gmx.de Tue Aug 5 07:44:14 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Tue, 05 Aug 2008 15:44:14 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <4898592E.2020908@gmx.de> Florian Manschwetus schrieb: > Michael Erskine schrieb: >>> Just look at sendCommand in this method I have to place a >>> Thread.sleep(20) after each byte send to get working. Even the event >>> based receive doesn't work fine but this could be may stupidness. >> >> Hi Florian, >> >> Yes, naturally you'll have to wait for a response from the other end. >> Why not wait for notification from the event thread perhaps using a >> BlockingDeque rather than your LinkedList. Generally I >> try to decouple all input and output streams: in your case your >> application is operating synchronously like the "expect" program >> (http://expect.nist.gov/) so waits (or timeouts) will need to be >> factored in. >> >> Regards, >> Michael Erskine. >> > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) > > Florian Furthermore there is this basic baud with this confusing javadoc entry: public boolean setBaudBase(int BaudBase) throws UnsupportedCommOperationException, java.io.IOException Extension to CommAPI. Set Baud Base to 38600 on Linux and W32 before using. maybe this could explain something Florian >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/006c7425/attachment-0047.bin From jredman at ergotech.com Tue Aug 5 09:13:36 2008 From: jredman at ergotech.com (Jim Redman) Date: Tue, 05 Aug 2008 09:13:36 -0600 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: Message-ID: <48986E20.3060104@ergotech.com> Trent, So two issues: 1) Technically I'm still not sure how easy/practical a layer would be. The problems are always classes like listeners, and wrapping returns of gnu.io classes. I really see it as a "delegate" type of concept. Any thoughts or ideas of the practicality of this approach? The idea is not to modify RXTX. 2) Javax. The javax namespace does seem to be in widespread use outside of Sun (the same is true for the java namespace). The classpath extensions, or some other location, should be interested in a JavaComm implementation even if it does have dependencies on RXTX. Would you have any philosophical objection to an approach like that? Of course, I suspect it might be better if someone with that authority at Sun would admit that the javax namespace is already in the wild and that there is no problem with it being used within RXTX. Jim Trent Jarvi wrote: > Hi Jim, > > I will not step into the javax.comm namespace without Sun's explicite > permission. I fully understand the pain point you are trying to address. > > In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java Comm > Linux) - which remains an integral part of rxtx. At the time it was a win for > Sun and rxtx. > > The Sun commapi license is/was fairly clear that rxtx should not step into that > namespace. It made sense as Sun was active in that space and rxtx may go into > another namespace - it was an experiment in working with Sun. > > This may sound silly looking at something that happened almost 10 years ago. > In a community of respect which Sun helped create, there is no question about > what to do. I hope eventually Sun will step up and do a right thing too. > > I agree that this is hurting the API more than helping it. There are also > questions about how to replace the API in the long term which includes HID > support which isn't going well so far. > > Others that can't even look at Sun's javax.comm today and can look at Kaffe's > contribution to classpathx can easily work around such restrictions. > > On Mon, 4 Aug 2008, Jim Redman wrote: > >> Has there been any work/would it be possible, to layer a javacomm >> look-alike on top of the GNU code? >> >> The goal is not to move the javax code forward, but to emulate the >> "legacy" javax packages for people who still need this. >> >> Jim >> >> Trent Jarvi wrote: >>> It would be nice to work with Sun to resolve those longstanding issues. >>> But it may not be practical unless the process goes as fast and painless >>> as the grandfathering of commapi did. >>> >>> Another option may be the old kaffe extensions that moved to gnu >>> classpathx. These don't have the native libraries but should provide >>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>> >>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From sandeep at genevasoftech.com Tue Aug 5 11:18:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Tue, 05 Aug 2008 22:48:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <48988B6C.5080409@genevasoftech.com> Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. *-- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/ad20f1cb/attachment-0047.html From Martin.Oberhuber at windriver.com Tue Aug 5 13:30:17 2008 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Tue, 5 Aug 2008 21:30:17 +0200 Subject: [Rxtx] librxtxSerial.so for Solaris 9 Message-ID: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Sandeep, shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on Sol7 but I've successfully run it on Sol9 and Sol10. Or is your request really about a native 64bit variant? I'm afraid that then you're out of luck since I think that quite a bit of RXTX is not yet ready for 64 bit. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Sandeep Kumar K Sent: Tuesday, August 05, 2008 7:19 PM To: rxtx at qbang.org Subject: [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so for Solaris 9 Hi, Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 bit machine. The librxtxSerial.so given in website is for Solaris 8. -- Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080805/81b7f988/attachment-0047.html From tjarvi at qbang.org Tue Aug 5 22:38:34 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 22:38:34 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: On Tue, 5 Aug 2008, Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built > on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid that > then > you're out of luck since I think that quite a bit of RXTX is not yet > ready > for 64 bit. > While rxtx-2.1-7 probably has problems, The CVS code should be OK for 64 bit Solaris. If it isn't, let me know and I'll find which patch is missing. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Aug 5 23:13:00 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Aug 2008 23:13:00 -0600 (MDT) Subject: [Rxtx] Sun's Comm API? In-Reply-To: <48986E20.3060104@ergotech.com> References: <48986E20.3060104@ergotech.com> Message-ID: On Tue, 5 Aug 2008, Jim Redman wrote: > Trent, > > So two issues: > > 1) Technically I'm still not sure how easy/practical a layer would be. The > problems are always classes like listeners, and wrapping returns of gnu.io > classes. I really see it as a "delegate" type of concept. Any thoughts or > ideas of the practicality of this approach? The idea is not to modify RXTX. I have not put too much thought into this. I assume you want what rxtx 2.0 provided to tie into javax.comm implementations. More classes could be added to rxtx 2.1-7 for SPI support. Maintaining rxtx-2.0 could also be handed to someone if they like. > > 2) Javax. The javax namespace does seem to be in widespread use outside of > Sun (the same is true for the java namespace). The classpath extensions, or > some other location, should be interested in a JavaComm implementation even > if it does have dependencies on RXTX. Would you have any philosophical > objection to an approach like that? > No problems. Classpathx would be a possible place to do it. I'd suggest thinking twice about what this involves in practical terms. You would be wanting to revive the 2.0 API while Sun is at 3.0 and grandfathering the JSR. This undermines the main reason (established api) for using the javax.comm namespace and does not leave such a project in a good position. The only win I see here is maintaining support for applications that can't migrate namespaces. Not that that isn't important. At some point it is going to be less work to just edit the bytecode :) Such a javax.comm effort would also be signing up new projects that decided to use the work up for concerns they probably will not understand or expect. That probably isn't a good path to facilitate for new projects at this time. We will put a good faith effort to work well with others but keep in mind the project has limited bandwidth for such efforts. > Of course, I suspect it might be better if someone with that authority at Sun > would admit that the javax namespace is already in the wild and that there is > no problem with it being used within RXTX. > > Jim > > Trent Jarvi wrote: >> Hi Jim, >> >> I will not step into the javax.comm namespace without Sun's explicite >> permission. I fully understand the pain point you are trying to address. >> >> In ~1999 I looked at commapi and worked with Kevin Hester's 'jcl' (Java >> Comm Linux) - which remains an integral part of rxtx. At the time it was a >> win for Sun and rxtx. >> >> The Sun commapi license is/was fairly clear that rxtx should not step into >> that namespace. It made sense as Sun was active in that space and rxtx may >> go into another namespace - it was an experiment in working with Sun. >> >> This may sound silly looking at something that happened almost 10 years >> ago. In a community of respect which Sun helped create, there is no >> question about what to do. I hope eventually Sun will step up and do a >> right thing too. >> >> I agree that this is hurting the API more than helping it. There are also >> questions about how to replace the API in the long term which includes HID >> support which isn't going well so far. >> >> Others that can't even look at Sun's javax.comm today and can look at >> Kaffe's contribution to classpathx can easily work around such >> restrictions. >> >> On Mon, 4 Aug 2008, Jim Redman wrote: >> >>> Has there been any work/would it be possible, to layer a javacomm >>> look-alike on top of the GNU code? >>> >>> The goal is not to move the javax code forward, but to emulate the >>> "legacy" javax packages for people who still need this. >>> >>> Jim >>> >>> Trent Jarvi wrote: >>>> It would be nice to work with Sun to resolve those longstanding issues. >>>> But it may not be practical unless the process goes as fast and painless >>>> as the grandfathering of commapi did. >>>> >>>> Another option may be the old kaffe extensions that moved to gnu >>>> classpathx. These don't have the native libraries but should provide >>>> the 2.0 interface and the javax.comm.properties mechansim for SPI. >>>> >>>> http://cvs.savannah.gnu.org/viewvc/comm/source/javax/comm/?root=classpathx >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > From sandeep at genevasoftech.com Wed Aug 6 00:03:36 2008 From: sandeep at genevasoftech.com (Sandeep Kumar K) Date: Wed, 06 Aug 2008 11:33:36 +0530 Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> Message-ID: <48993EB8.30107@genevasoftech.com> Thank you Mr. Martin for your suggestion. The native file which is given in rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am getting the following error . Any suggestions to solve this issue. I am using Solaris SPARC 64 bit machine. ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) thrown while loading gnu.io.RXTXCommDriver Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch) at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(Unknown Source) at java.lang.ClassLoader.loadLibrary(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) at com.ReadFromModem.main(ReadFromModem.java:84) * * *Thanks & Regards Sandeep Kumar K Sr. Software Engineer Geneva Software Technologies Whitefield, Bangalore Mob : 9880193454* Oberhuber, Martin wrote: > Sandeep, > > shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse > variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on > Sol7 but I've successfully run it on Sol9 and Sol10. > > Or is your request really about a native 64bit variant? I'm afraid > that then > you're out of luck since I think that quite a bit of RXTX is not yet ready > for 64 bit. > > Cheers, > -- > *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* > Target Management Project Lead, DSDP PMC Member > http://www.eclipse.org/dsdp/tm > > > > ------------------------------------------------------------------------ > *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On > Behalf Of *Sandeep Kumar K > *Sent:* Tuesday, August 05, 2008 7:19 PM > *To:* rxtx at qbang.org > *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so > for Solaris 9 > > Hi, > > Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 > bit machine. The librxtxSerial.so given in website is for Solaris 8. > > *-- > > Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/1e920343/attachment-0047.html From tjarvi at qbang.org Wed Aug 6 00:21:42 2008 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Aug 2008 00:21:42 -0600 (MDT) Subject: [Rxtx] librxtxSerial.so for Solaris 9 In-Reply-To: <48993EB8.30107@genevasoftech.com> References: <460801A4097E3D4CA04CC64EE648584806E6CFB9@ism-mail03.corp.ad.wrs.com> <48993EB8.30107@genevasoftech.com> Message-ID: Hi Sandeep You may be out of luck unless you can compile the 2.1 src in CVS (requires gnu make and gcc). But you could try the ToyBox(R)(TM) which is a collection of WiLdLy untested cross compiled 2.1-7 binaries covering everything from the ibm z series to embeded arm/ppc. To give an idea how poorly these are tested, I don't even know if z series machines have a serial port. ftp://www.qbang.org/pub/rxtx/ToyBox/2.1-7-build1/Solaris They should at least match the binary types. Actually, I think if you use the rxtx jar from CVS with that file, it should 'work' as the fix for 64 bits was in java not the native code. You could just cd rxtx*/src; javac *.java then jar -cf RXTXcomm.jar `find -name \*.class` to create the hybrid which will complain about version information a bit. On Wed, 6 Aug 2008, Sandeep Kumar K wrote: > Thank you Mr. Martin for your suggestion. The native file which is given in > rxtx website is for solaris 2.8 when I try to use it in solaris 2.9 I am > getting the following error . > Any suggestions to solve this issue. > I am using Solaris SPARC 64 bit machine. > > ROMFTBE1(root)!!/tmp >java -jar ReadFromModem.jar > java.lang.UnsatisfiedLinkError: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF class: ELFCLASS64 > (Possible cause: architecture word > width mismatch) thrown while loading gnu.io.RXTXCommDriver > Exception in thread "main" java.lang.UnsatisfiedLinkError: > /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: > ld.so.1: java: fatal: /usr/jre1.6.0_07/lib/sparc/librxtxSerial.so: wrong ELF > class: ELFCLASS64 (Possible cause: > architecture word width mismatch) > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(Unknown Source) > at java.lang.ClassLoader.loadLibrary(Unknown Source) > at java.lang.Runtime.loadLibrary0(Unknown Source) > at java.lang.System.loadLibrary(Unknown Source) > at gnu.io.CommPortIdentifier.(CommPortIdentifier.java:83) > at com.ReadFromModem.main(ReadFromModem.java:84) > > * > * > > *Thanks & Regards > > Sandeep Kumar K > Sr. Software Engineer > Geneva Software Technologies > Whitefield, Bangalore > Mob : 9880193454* > > > > Oberhuber, Martin wrote: >> Sandeep, >> shouldn't Sol8 and Sol9 be compatible? You can give a try to the Eclipse >> variant from http://rxtx.qbang.org/eclipse/downloads/ , it's been built on >> Sol7 but I've successfully run it on Sol9 and Sol10. >> Or is your request really about a native 64bit variant? I'm afraid that >> then >> you're out of luck since I think that quite a bit of RXTX is not yet ready >> for 64 bit. >> Cheers, >> -- >> *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River* >> Target Management Project Lead, DSDP PMC Member >> http://www.eclipse.org/dsdp/tm >> >> ------------------------------------------------------------------------ >> *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On >> Behalf Of *Sandeep Kumar K >> *Sent:* Tuesday, August 05, 2008 7:19 PM >> *To:* rxtx at qbang.org >> *Subject:* [Suspected Spam][Blocked Sender][Rxtx] librxtxSerial.so >> for Solaris 9 >> >> Hi, >> >> Do anybody have librxtxSerial.so for Solaris 9. It is a SPARC 64 >> bit machine. The librxtxSerial.so given in website is for Solaris 8. >> >> *-- >> Thanks & Regards >> >> Sandeep Kumar K >> Sr. Software Engineer >> Geneva Software Technologies >> Whitefield, Bangalore >> Mob : 9880193454* >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> From michael.erskine at ketech.com Wed Aug 6 01:39:28 2008 From: michael.erskine at ketech.com (Michael Erskine) Date: Wed, 6 Aug 2008 08:39:28 +0100 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <4898556F.8000208@gmx.de> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> Message-ID: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Florian Manschwetus wrote: > Ok, sounds fine for the receiving problem. > But why i have to wait after each byte when sending a command squence? > (the for loop in send command) Hi Florian, I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. Regards, Michael Erskine. From florianmanschwetus at gmx.de Wed Aug 6 02:53:16 2008 From: florianmanschwetus at gmx.de (Florian Manschwetus) Date: Wed, 06 Aug 2008 10:53:16 +0200 Subject: [Rxtx] problems with timing using rxtx 2.1.7.2 (gentoo main portage tree install) (size reduced resend) In-Reply-To: <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> References: <48971C1F.9020806@gmx.de> <489833CE.1040801@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642A35@no-sv-03.ketech.local> <4898556F.8000208@gmx.de> <06BA3262D918014F9183B66425D5A8D431CC642B1B@no-sv-03.ketech.local> Message-ID: <4899667C.6010706@gmx.de> Michael Erskine schrieb: > Florian Manschwetus wrote: >> Ok, sounds fine for the receiving problem. >> But why i have to wait after each byte when sending a command squence? >> (the for loop in send command) > > Hi Florian, > I'd imagine you probably don't! You could send all bytes in one go and RXTX would send them. The problem is most probably the other end: perhaps it has a really small buffer, some non-standard UART, or a crazy timing issue. If you attach a terminal to your output and send all the bytes of a command in one go they should appear no problem. > > Regards, > Michael Erskine. > correct with a terminal on the other end it works, my idea was that this basic baud has some influence. Could some one explain what it is for? Florian > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3686 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20080806/c2b4fa84/attachment-0047.bin From rick_knight at rlknight.com Wed Aug 6 13:01:07 2008 From: rick_knight at rlknight.com (Rick Knight) Date: Wed, 06 Aug 2008 12:01:07 -0700 Subject: [Rxtx] Sun's Comm API? In-Reply-To: References: <48975796.4010600@rlknight.com> Message-ID: <4899F4F3.3020707@rlknight.com> Bruce Boyes wrote: > At 13:25 08/04/2008, Rick Knight wrote: >> I have an application that requires the javax compatible version of RXTX >> and Sun's comm api. I've been able to download and extract the version >> of RXTX that I need (2.0-7pre2) but I can't find Sun's camm api >> anywhere. Can someone tell me where I can find it? Or maybe send me a > > javaxcomm has had a sort of on-again off-again history. The windoze > version has been languishing for years (literally) but there are newer > versions for other OS's. > > We try to keep links on one of our help pages current: > http://www.practicalembeddedjava.com/tools/javatools_list.html > which gets you to here: > http://java.sun.com/products/javacomm/ > where it says in fact they no longer even support Windows and Mac: > "Implementations of the API are currently available for Solaris SPARC, > Solaris x86, and Linux x86." Too bad jvaxcomm wasn't open sourced so > someone could support it. But I guess that's part of the reason RXTX > exists! > > So one of Sun's own products, SunSPOT, has